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Abstract 


The  goal  of  this  project  was  to  develop  computer  technology  to  make  available  to  Air 
Mobility  Command  (AMC)  flight  personnel  (flight  planners,  managers  and  pilots),  in  a 
more  timely  and  effective  way,  the  flight-safety  critical  information  contained  in  a  set  of 
internationally  distributed  text  messages  known  as  Notices  to  Airmen  (NOTAMs). 

Briefly  put,  NOTAMs  are  notices  containing  information  (not  known  sufficient /y  in 
advance  to  publicize  by  other  means}  concerning  the  establishment ,  condition,  or 
change  in  any  aeronautical  facility,  service ,  procedure,  or  hazard,  the  timely  knowledge 
of  which  is  essential  to  personnel  concerned  with  flight  operations.  This  project  was 
initiated  as  part  of  the  Integrated  Flight  Management  (IFM)  Advanced  Technology 
Demonstration  (ATD),  whose  goals  were  to  “....advance  the  search,  retrieval,  handling, 
use  and  dissemination  of  raw  resource  data  and  refined  information  that  is  required  by 
Air  Mobility  Command  (AMC)  as  it  pertains  to  their  mission  planning  and  the  optimal  use 
of  the  available  mobility  resources.” 

In  order  to  automate  the  search,  retrieval,  and  dissemination  of  NOTAMs,  it  is 
essential  that  the  critical  parts  of  the  information  content  of  NOTAMs  be  made 
“understandable”  to  computers.  However,  NOTAMs  were  never  designed  to  be 
understood  by  computers  -  they  are  essentially  free-text  messages  written  by  people  in 
over  160  countries,  and  intended  to  be  interpreted  by  other  human  beings.  In  order  to 
make  such  free  text  understandable  by  machines,  there  are  two  challenges  - 

1 )  The  NOTAM_  parsing  [problem  -  extracting  key  information  from  free  text, 
despite  wide  variations  in  form  (syntax)  and  content  (semantics)  and  non¬ 
trivial  numbers  of  errors,  both  typographical  and  otherwise 

2)  The  NOTAM  representation  /problem  -  providing  a  formal  representation  of 
the  extracted  information  content  the  will  facilitate  reasoning  by  a  computer 
system  to  determine  whether  a  given  NOTAM  is  relevant  to  a  given  flight  (e.g. 
do  the  geographical  and  three  dimensional  regions  covered  by  NOTAM 
intersect  the  flight  plan,  is  the  NOTAM  in  effect  at  the  expected  time  of  the 
flight,  and  is  the  change  in  airspace/facility  characteristics  likely  to  affect  the 
type  of  aircraft  involved,  performing  the  specified  mission). 

At  the  time  this  research  was  started,  the  only  “parsing”  that  had  been  done  of 
NOTAMs  was  simple  string  pattern  matching,  looking  for  single  words  such  as 
“CLOSED”,  and  the  particular  codes  that  were  contained  as  part  of  the  message. 
Although  NOTAMs  are  supposed  to  be  issued  in  English  (no  matter  what  country  issues 
them),  no  attempt  had  been  made  to  use  sophisticated  natural-language  parsers  to 
extract  information.  The  pattern  matching  approaches  produced  large  numbers  of  “false 
alarms”  (indications  that  NOTAMs  were  critical  for  given  flights),  and  tended  to  swamp 
AMC  personnel. 

In  order  to  solve  the  NOTAM  parsing  problem  we  had  to  develop  a  new  parsing 
system,  employing  and  extending  ideas  developed  by  the  information-extraction 
community,  rather  than  on  classical  computational  linguistics.  The  initial  expectation  of 
this  project  had  been  that  we  would  be  able  to  take  a  computational-linguistics 
approach,  and  modify  existing  English-language  parsers  to  handle  the  NOTAM  text. 
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After  examining  the  first  set  of  30,000  NOTAMs,  it  became  clear  that  this  would  not  be 
feasible.  The  vocabulary  in  NOTAMs  was  highly  specialized,  filled  with  jargon  and 
abbreviations  not  covered  by  standard  parsers.  They  were  filled  with  non-standardized 
domain-specific  phrases  describing  flight  procedures  and  equipment,  geographical 
regions,  altitude  restrictions,  etc.  It  also  became  clear  that  the  number  of  variant 
spellings  of  key  words  was  quite  high,  and  that  misspellings  and  typos  were  common. 
Punctuation  was  dropped  and  added  and  used  in  non-standard  ways.  Finally,  it  became 
clear  that  even  ignoring  errors  and  specialized  phraseology,  the  basic  structure  of  the 
language  was  not  in  general  like  standard  English.  Because  native  speakers  from  160 
countries  were  attempting  to  communicate  in  English,  the  result  was  linguistically  less 
like  a  standard  language  like  English  or  French  and  more  like  what  linguists  term  a 
“pidgin.”  To  handle  these  and  other  problems  we  developed  a  parsing  technology  based 
on  the  concept  of  “cascaded  finite-state  automata”,  which  made  it  possible  to  quickly 
extract  complex  local  phrases  without  requiring  that  the  overall  structure  of  the  NOTAM 
looked  anything  like  a  sequence  of  well-formed  sentences.  The  resulting  parser,  which 
we  call  FIST  (Hnite  State  Transducer),  is  not  only  robust  in  response  to  the  errors 
discovered  in  the  worldwide  set  of  NOTAMs,  but  is  extremely  fast  (parsing  8  NOTAMs, 
with  average  length  of  more  than  50  “words”,  in  under  a  second  on  a  2.1  Ghz  Pentium 
M  processor).  Additionally,  because  the  definition  of  the  airspace  is  constantly 
changing,  new  vocabulary  is  added  and  old  words  retired  on  a  monthly  basis,  and  the 
information  specifying  this  is  buried  in  databases  issued  by  various  agencies  such  as 
the  National  Geo-Spatial  Intelligence  Agency  (NGA). 

This  project  has  had  a  number  of  important  spinoffs.  The  project  was  originally 
intended  as  primarily  a  research  and  prototyping  effort  to  determine  how  far  we  could  go 
in  meeting  AMC’s  needs  by  attacking  the  NOTAM  parsing  and  representation  problem. 
However,  early  progress  in  the  parsing  effort,  led  to  BBN  producing  an  unplanned, 
unfunded  connection  to  the  GAMAT  Global  Weather  Management  situation  awareness 
and  decision  support  project  being  performed  for  AFRL’s  Human  Effectiveness 
Directorate  in  support  of  AMC.  AFRL/IF  and  AFRL/HECS  enthusiastically  supported  this 
collaboration  after  the  initial  demonstration  of  what  could  be  done,  and  this  in  turn  led  to 
its  integration  into  a  major  set  of  Air  Force  demonstrations  called  the  Global  Conops 
Synchronization  demonstration  (or  the  “CAF-MAF”  demo  -  the  Combat  Air 
Force/Mobility  Air  Force  information  interchange  demonstration).  This  demonstration 
led  to  requests  by  senior  Air  Force  personnel  that  this  capability  be  evaluated  as  part  of 
the  Air  Force  JEFX  2004  Exercise.  Success  in  this  exercise  led  to  the  decision  to 
incorporate  some  form  of  this  NOTAMs  parsing  capability  into  a  Common  Component  of 
the  Joint  Mission  Planning  System  (JMPS),  and  to  requests  (and  funding)  by  NGA  to 
use  this  capability  to  help  them  maintain  models  of  vertical  obstructions  in  the  airspace. 
Outside  the  DoD,  the  FAA  and  commercial  aviation  organizations  like  Jeppesen 
expressed  interest  in  this  capability,  and  as  part  of  the  JMPS  program  this  capability  is 
being  tied  in  to  the  FAA  NAIMES  (NAS  Aeronautical  Information  Management 
Enterprise  System)  system.  Finally,  EUROCONTROL  (the  European  Organisation  for 
the  Safety  of  Air  Navigation)  has  expressed  interest  in  this  technology  and  requested  a 
briefing  on  the  system  in  September  2004. 


The  success  of  this  project  has  been  exciting  for  its  participants  and  sponsors,  but 
the  resulting  move  from  research  effort  to  deployment  leads  to  concerns  that  must  be 
raised  strongly  here.  It  is  important  to  note  that  while  this  project  has  transitioned 
capability  to  various  other  Air  Force  and  Department  of  Defense  programs,  the 
NOT  AMs  parsing  problem  and  the  NOTAMs  representation  problem  are  not  fully 
solved.  In  fact,  given  the  extreme  variety  in  types  of  language  used  within  NOTAMs, 
the  level  of  errors  introduced  by  human  NOTAM  writers,  and  the  constantly  changing 
nature  of  the  airspace  (and  hence  airspace  announcements),  we  believe  that  no  fully 
automated  system  will  be  able  to  extract  and  correctly  represent  all  of  the  critical 
information  content  of  every  NOTAM  issued.  Thus  it  should  not  be  expected  that  the 
current  NOTAMs  parser  produces  error-free  output  for  all  NOTAMs,  and  it  is  critical 
that  the  NOTAMs  parser  be  used  as  part  of  a  combined  human/automated 
system.  Trained  human  beings  must  continue  to  take  responsibility  for  safety-of- 
flight  issues.  It  is  important  to  bear  in  mind  that  the  goal  of  the  project  (and  thus  the 
resulting  system)  is  to  provide  robust  enough  parsing  so  that  the  overall  operations  of 
AMC  can  be  improved  by  reducing  workload  associated  with  distributing  NOTAMs. 
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Introduction 

This  project  was  initiated  as  part  of  the  Integrated  Flight  Management  (IFM)  Advanced 
Technology  Demonstration  (ATD),  whose  goals  were  to  “....advance  the  search, 
retrieval,  handling,  use  and  dissemination  of  raw  resource  data  and  refined  information 
that  is  required  by  Air  Mobility  Command  (AMC)  as  it  pertains  to  their  mission  planning 
and  the  optimal  use  of  the  available  mobility  resources.” 
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Figure  1:  Information  flow  required  for  planning  AMC  missions 

As  noted  in  the  diagram  from  the  draft  Mobility  2000  Concept  of  Operations,  a  key 
part  of  the  information  flow  required  for  planning  and  executing  AMC  missions  consists 
of  Notices  to  Airman  (NOTAMs).  In  order  to  understand  this  project,  it  is  important  to 
understand  what  NOTAMs  are,  why  they  are  critical  to  AMC  operations,  and  what 
challenges  they  pose  to  automated  processing. 

NOTAMs :  Safe,  efficient  and  effective  flight  planning,  flight  management  and  flight 
operations  by  AMC  (as  well  as  other  Air  Force  commands,  other  DoD  components,  and 
the  aviation  community  in  general)  requires  timely  and  up-to-date  knowledge  of  the 
conditions  and  characteristics  of  aviation  facilities,  procedures,  and  services,  as  well  as 
the  existence  and  characteristics  of  hazards  to  flight.  The  bulk  of  this  information  is 
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known  in  advance,  stable  over  long  periods  of  time,  and  is  published  in  standard,  well- 
defined  publications  reissued  periodically  at  standard  times  by  various  national  and 
international  aeronautical  organizations  (e.g.  the  Federal  Aviation  Administration  (FAA) 
and  Department  of  Defense  in  the  United  States,  the  International  Civil  Aviation 
Organization  (ICAO),  EUROCONTROL  (the  European  Organization  for  the  Safety  of 
Air  Navigation)  and  the  national  aviation  authorities  of  most  member  nations  of  the 
United  Nations.). 

It  is  the  responsibility  of  each  pilot  (and  other  members  of  the  flight  planning  and 
management  community  such  as  AMC  flight  managers  and  planners)  to  read  such 
official  publications  and  stay  abreast  of  all  of  this  information  for  all  airspace  through 
which  a  sortie  is  planned  to  navigate  and  facilities  it  is  expected  to  use.  However,  there 
are  always  unanticipated  and/or  short-term  changes  in  these  conditions  and 
characteristics  which  must  be  transmitted  on  short  notice  to  pilots  and  others  by 
electronic  means.  This  function  is  handled  by  NOTAMs. 

NOTAMs  are  time-critical,  safety-critical  announcements  of  temporary  changes  to 
global  flight  conditions.  They  cover  much  of  the  aerospace  flight  environment  such  as 
the  condition  and  availability  of  many  airport  facilities  (including  runways, 
instrumentation,  fuel,  etc),  flight  /  navigational  aids,  restrictions  on  airspace  (weather, 
political,  commercial,  etc)  and  a  great  variety  of  air  traffic  regulations  and  flight  related 
concerns.  There  are  around  30,000  active  NOTAMs  at  any  given  time,  updated  at  a  rate 
of  several  thousand  per  day.  -  the  key  operational  question  is  how  to  make  sure 
aircrews  and  planners  get  the  right  information  in  a  timely  fashion. 

The  particular  goal  of  this  project  was  to  address  AMC’s  critical  need  to  quickly 
identify  and  flag  mission  impacting  NOTAMs  to  the  Tanker  Airlift  Control  Center  (TACC) 
Flight  Manager  (FM). 

To  get  some  feeling  for  the  variety  of  NOTAMs  that  must  be  handled,  we  can  look  at 
various  distributions  of  NOTAMs,  e.g.  by  country  and  by  topic.  On  a  typical  day,  while 
there  may  be  up  to  160  countries  represented,  out  of  30,000  NOTAMs,  there  are  10,000 
US  NOTAMS,  3000  Italian,  1400  German,  and  1000  British  NOTAMs.  This  distribution 
has  important  consequences  because  experience  has  shown  us  that  there  are 
noticeable  and  strong  variations  in  the  way  that  various  issues  are  reported,  differing  by 
nation  (and  many  regions,  airfields  and  probably  even  particular  human  NOTAM 
reporters).  The  fact  that  over  half  of  the  NOTAMs  issued  come  from  a  handful  of 
countries  simplifies  things  somewhat,  but  it  leads  to  a  situation  where  there  is  a  long 
“tail  of  the  distribution”  (rare,  but  actually  seen  variations)  of  different  ways  to  express 
common  issues. 

To  assess  distribution  by  topic,  we  can  make  use  of  human  entered  QCODEs 
contained  in  many  NOTAMS.  These  are  five  character  codes  defined  by  ICAO  (the 
International  Civil  Aviation  Organization)  and  extended  by  the  US  Department  of 
Defense.  ICAO  and  DoD  requirements  specify  that  all  NOTAMs  should  contain 
QCODEs,  though  this  requirement  is  clearly  not  followed  universally.  These  QCODEs 
are  supposed  to  represent  the  overall  topic  of  the  NOTAM.  Appendix  0  lists  the  official 
ICAO  QCODEs.  On  a  typical  recent  (2006)  day  with  about  30,000  active  NOTAMs  there 
were  7500  NOTAMs  without  QCODEs,  and  3000  with  the  QCODE  “QXXXX”  which  is 
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supposed  to  mean  “no  QCODE  topic  applicable,  reported  in  plain  text”  but  by  inspection 
seems  to  most  often  mean  “the  author  didn’t  have  time  to  look  up  the  appropriate 
QCODE”.  The  next  most  common  QCODEs  are  “QOL..”  (2000)  and  “QOB..”  (1300) 
which  talk  about  vertical  obstructions  (QOB..)  and  the  lights  on  them  (QOL..),  followed 
by  “QMRLC”  -  runway  closed  -  (700) ,  “QPICH”  -  instrument  procedure  changed  (650), 
followed  by  “QFAXX”  -  an  unspecified  fact  about  the  airfield  as  a  whole  -  (500).  Again, 
there  are  some  QCODEs  for  which  we  have  a  lot  of  data  for  how  the  content  is 
represented  in  the  plain  text,  but  there  is  a  huge  tail  of  low  likelihood  variations  that  a 
system  must  deal  with. 

If  QCODEs  were  universally  applied  and  accurate,  this  would  go  a  major  part  of  the 
way  in  identifying  critical  NOTAMs.  Unfortunately,  as  indicated  above,  no  more  than 
65%  of  NOTAMs  have  meaningful  QCODEs,  and  closer  inspection  indicates  that  of 
those  NOTAMs  with  QCODEs,  there  are  problems  in  >  10%  (inaccuracies,  or  missing 
information  due  to  use  of  the  “XX”  suffix  which  means  “unspecified  report”,  or  NOTAMs 
which  report  multiple  facts,  but  are  constrained  to  use  only  one  QCODE  -  e.g.  the 
modification  of  an  instrument  procedure  caused  by  the  existence  of  a  temporary  or 
permanent  vertical  obstruction). 

The  NOT  AM  Parsing.  (and_  Representation)  Problem:  At  any  given  time,  there  are  on 
the  order  of  30,000  NOTAMs  in  force  (active  NOTAMs),  with  approximately  3,000-4,000 
NOTAMs  issued  each  day  (and  an  equivalent  number  being  cancelled  or  expiring).  For 
an  organization  like  AMC  with  a  global  and  constantly  changing  mission,  the  problem  is 
how  to  keep  flight  personnel  abreast  of  the  relevant  changes  to  the  airspace,  and  to 
recognize  when  planned  or  currently  flying  missions  may  be  impacted  by  such  changes, 
without  drowning  already  heavily  burdened  flight  managers  and  pilots  with  unrelated 
NOTAMs.  The  goal  of  this  project  was  to  determine  how  much  could  be  done  with 
automated  parsing  and  knowledge  representation  technology  to  meet  these  needs. 


The  Operation  Context  of  the  Problem 

At  the  start  of  this  project,  the  process  of  getting  NOTAM  information  relevant  to  an 
AMC  sortie  was  still  a  primarily  manual  operation.  This  has  remained  true  even  with  the 
increasing  use  of  computerized  systems  such  as  Integrated  Management  Tool  (IMT)  by 
flight  managers,  and  access  to  NOTAMs  from  the  Defense  Internet  NOTAM  Service 
(DINS)  web-based  service.  The  process  of  “papering  the  crew”,  which  includes 
providing  the  crew  with  the  collection  of  NOTAMs  relevant  to  their  sortie,  requires 
substantial  manual  attention  from  the  flight  manager.  We  indicate  some  of  the 
dimensions  of  this  problem  by  using  material  from  a  briefing  by  AMC  personnel.  Even 
after  the  operational  installation  of  the  IMT  system  the  process  looked  like  the  following: 

Given  a  flight  plan  provided  within  IMT,  the  FM  uses  IMT  to  pull  up  NOTAMs  from 
DINS.  This  is  a  manual  data  pull  that  requires  continual  polling  to  remain  current. 
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The  DINS  query  mechanism  is  primarily  limited  to  query  by  issuing  location,  and  this 
is  primarily  used  to  find  NOTAMs  for  the  Departure  and  Destination  International  Civil 
Aviation  Organization  (ICAO)  codes  only.  ICAO  codes  are  4-letter  airport  identifier 
codes  that  uniquely  identify  individual  airports  worldwide.  Usually,  the  first  two  letters  of 
ICAO  codes  identify  the  country.  However,  ICAO  codes  for  airports  in  the  continental 
United  States  begin  with  a  “K”,  and  are  followed  by  the  three-letter  International  Air 
Transport  Association  (IATA)  airport  code  that  airline  passengers  are  used  to  seeing. 

NOTAMs  for  selected  (primary)  alternates  can  also  be  added,  to  make  sure  of 
catching  all  NOTAMs  that  might  affect  the  flight.  Additionally  the  FM  can  request 
NOTAMs  issued  by  various  other  offices,  such  as  the  individual  Flight  Information 
Region  (FIR)/Upper  Flight  Information  Report  (UIR)/Air  Route  Traffic  Control  Center 
(ARTCC)  regional  centers  controlling  the  regions  that  the  flight  goes  through,  as  well  as 
more  general  NOTAMs  such  as  those  issued  by  KFDC  (Washington,  DC),  ATTA, 

ATTN,  ATTC,  ATTP,  KZZZ  and  KGPS. 
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Figure  3:  The  DINS  Web  Interface 


To  simplify  retrievals,  DINS  has  a  geographic  search  mechanism,  but  this  is  based 
on  the  issuing  location  as  well,  and  is  restricted  to  queries  based  on  great  circle  routes. 
There  is  no  mechanism  to  make  use  of  detailed  computer  readable  flight  plans  to 


Figure  4:  Using  the  DINS  web  interface  via  ICAO  Ids 
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Manual  information  pull  with  query  limited  to  location  limits  automating  the  process 
for  a  number  of  reasons: 

•  Because  there  is  no  way  to  filter  the  NOTAMs  based  on  spatial  or  temporal 
extent,  or  on  classes  of  airspace  restrictions  or  equipment/facilities/procedures 
impacted,  the  choice  is  often  between  providing  too  few  NOTAMs  to  the  crew,  or 
too  many.  It  might  seem  that  providing  a  larger  set  of  NOTAMs  than  are  actually 
relevant  would  be  appropriate  as  a  way  to  avoid  missing  critical  NOTAMs,  in 
practice  this  leaves  it  up  to  the  crew  to  search  through  what  can  be  hundreds  of 
NOTAMs  in  a  flight  over  Europe,  almost  all  of  which  are  irrelevant  to  the  actual 
flight  path. 

•  There  is  no  way,  short  of  constant  polling  by  the  FM  to  find  new  NOTAMs  that 
become  relevant  to  the  flight,  or  to  find  NOTAMS  that  are  no  longer  relevant. 
Note  that  aircrews  do  not  receive  in-flight  updates  of  new  or  changing  NOTAMS. 

•  During  the  (sometimes  quite  long)  period  between  initial  planning  and  the 
beginning  of  FM  operations  (typically  around  24  hours  before  the  launch  of  the 
sortie),  NOTAMs  that  might  require  re-planning  of  the  sortie  are  not  monitored. 
Thus: 

Missions  planned  months  prior  to  execution  may  become  obsolete  when 
relevant  NOTAM  information  changes 

Contingency  planning  is  required  when  transitioning  from  planning  to 
execution. 

Project  Goals 

This  project  was  initiated  as  a  one-year  effort  with  an  original  period  of  performance  of 
July  1 1 , 2002  through  July  10,  2003.  The  focus  of  this  project  was  to  determine  the 
feasibility  of  using  parsing  technology  to  solve  the  NOTAM  problems  described  above. 
We  proposed  to  develop  techniques  that  could  be  used  to  reduce  the  workload  of  the 
AMC  FM  and  provide  focused  information  to  flight  crews,  by  developing  a  set  of 
automated  tools  to  translate  the  message  based,  free  text  (NOTAM)  information  into 
machine-representations  suitable  for  presentation  to  automated  decision  systems.  This 
project  was  conceived  to  be  the  initial  step  in  producing  a  more  complete  Intelligent 
Distribution  and  Inference  system  for  NOTAMs,  extending  the  concept  introduced  in  the 
AFRL  Intelligent  Distribution  of  NOTAMs  (IDiON)  system,  but  it  was  not  in  and  of  itself 
expected  to  produce  such  a  full  system. 
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Figure  5:  ISQ  NOTAMs  project  goals  and  efforts  beyond 


Deliverable 
from  project 


Future  work 


The  original  project  tasks  with  commentary: 

•  Establish  the  specific  requirements  including  the  sets  of  NOTAMs  to  be 
translated,  the  data  sources  to  be  used  and  the  decision  support  system(s) 
within  the  Mobility  Air  Force  Research  and  Development  Facility  (MAF/RDF) 
to  be  used  in  the  demonstrations. 

o  It  was  recognized  in  the  project  proposal  that  it  would  be  impossible  to 
produce  a  system  to  completely  parse  all  NOTAMs  within  the  available 
resources,  so  the  goal  was  to  determine  a  sub-set  of  the  NOTAM  stream 
that  would  provide  value  to  the  FMs  and  would  demonstrate  the  potential 
value  of  a  more  complete  solution. 

o  The  original  concept  was  to  prototype  this  by  integration  with  the  AFRL 
IDiON  system,  but  as  the  development  of  that  system  was  a  limited 
duration  AFRL/IF  in-house  project,  the  government  requested  that  we 
develop  a  more  generally  applicable  interface  to  allow  for  use  of  the  base 
technology  in  any  of  a  number  of  potential  applications. 

•  Based  on  the  requirements  identified,  develop  and  implement  an  ontology 
to  represent  the  NOTAM  information  content. 

o  This  was  originally  characterized  as  a  DAML+OIL  ontology,  the  existing 
US/EU  standard  for  web  ontologies.  As  the  project  continued,  this  was 
changed  to  make  use  of  the  World  Wide  Web  Consortium  (W3C)  Web 
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Ontology  Language  (“OWL”)  standard1  that  was  developed  out  of 
DAML+OIL. 

•  Develop  natural  language  processing  modules  to  translate  NOTAM  text  into 
the  chosen  ontology. 

•  Develop  a  Graphical  User  Interface  (GUI)-based  ontology  annotation  viewer 
and  editor  to  allow  a  user  to  rapidly  review  and  revise  the  annotations 
produced  by  the  automated  components. 

•  Design  and  develop  and  infrastructure  fitting  the  various  components,  the 
stored  NOTAM  ontology,  the  natural  language  processing  modules  and  the 
GUI  viewer/editor  together  and  make  it  accessible  in  a  general  manner  to 
support  other  automated  systems. 

This  initial  project  was  extended  in  a  number  of  ways  as  it  became  clear  that  the 
resulting  technology  could  be  used  by  the  Air  Force,  elsewhere  in  the  Department  of 
Defense  (DoD),  and  within  many  other  potential  commercial  applications.  This  has  led 
to  the  current  situation  where  a  version  of  the  NOTAMs  technology  is  being  installed  at 
the  National  Geospatial-Intelligence  Agency  (NGA),  and  another  descendant  of  the 
technology  is  being  developed  as  part  of  the  Joint  Mission  Planning  System  (JMPS) 
Global  Planning  Common  Component  (GPCC).  Some  of  these  efforts  were  supported 
by  extensions  to  the  initial  AFRL  NOTAMs  contract,  while  others  have  resulted  in  sub¬ 
contracts  under  the  JMPS  program.  We  include  a  brief  history  of  this  progression. 

NOTAMs/GAMAT  linkage 

During  the  first  six-months  of  the  contract,  after  initial  work  on  the  parsing  system  and 
knowledge  representation,  BBN  realized  that  there  was  a  potential  for  providing  the  AF 
with  a  much  more  valuable  product  by  integrating  technologies  being  developed  for  two 
different  AFRL  projects,  both  supporting  AMC  - 

•  This  ISQ  NOTAMs  project,  supported  by  AFRL/IFSA  at  Rome  NY 

•  The  Global  Air  Mobility  Advanced  Technology  (GAMAT)  Global  Weather 
Management  project  supported  by  AFRL/HECS  at  Wright  Patterson  OH 


1  A  major  requirement  of  this  project  was  that  the  resulting  technology  be  as  widely  applicable  as  possible  -  it  was 
not  clear  throughout  most  of  the  project  what  the  transition  path  would  be  if  the  technology  was  successfully 
adapted,  so  we  made  a  strong  effort  to  build  on  the  most  open  existing  standards  for  providing  information  from  the 
parser  to  other  systems.  In  particular,  we  focused  on  an  XML-based  web-service  standard,  since  this  would  allow 
the  results  of  the  parsing  to  be  made  available  to  other  systems  on  different  computers,  written  in  any  of  a  very  wide 
variety  of  computer  languages.  Since  we  were  generating  a  semantic  representation  of  the  results  of  parsing  (a 
representation  of  the  meaning  of  NOTAMs  that  could  be  understood  and  reasoned  with  by  computers)  we  initially 
chose  to  use  the  most  widely  specified  standard  for  such  information.  This  was  the  DAML+OIL  XML  ontology 
language  developed  by  combining  the  best  features  of  government  sponsored  research  languages  DAML  (the  US 
Defense  Advanced  Research  Projects  Agency  ontology  language)  and  OIL  (the  Ontology  Interchange  Language 
defined  by  the  European  community).  Luckily,  at  the  time  we  started  the  project  these  two  potentially  competing 
standards  had  been  merged.  During  the  course  of  the  project,  the  W3C  (World  Wide  Web  Consortium  -  the 
international  industry  consortium  dedicated  to  building  consensus  around  Web  technologies,  the  de  facto  standards 
body  for  all  web-based  languages  and  services)  took  DAML+OIL  and  produced  the  broader  OWL  standard.  By 
adhering  to  this  standard,  we  hope  to  make  the  results  of  our  parsing  and  interpretation  of  NOTAMs  readily 
accessible  to  any  application  with  a  need  for  information  about  NOTAMs. 
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The  GAMAT  system  was  designed  as  a  decision  support  and  collaboration  system  to 
support  interaction  between  flight  managers  and  the  weather  shop  at  AMC.  It  retrieved 
information  about  current  and  planned  AMC  sorties,  as  well  a  wide  variety  of  weather 
related  information,  and  provided  a  way  for  FMs  to  see  these  sorties  in  a  map-based 
display.  Additionally,  it  provided  computer  agent-based  systems  to  reason  about  the 
potential  effects  of  weather  on  these  sorties,  and  to  provide  automatic  alerts  when 
changing  weather  information  indicated  potential  problems  for  flights.  This  system  was 
designed  using  the  Work-Centered  Support  System  technology  supported  by  AFRL/HE, 
and  was  already  operational  as  a  prototype  within  AMC. 

These  two  systems  were  both  under  development  by  groups  within  the  same  BBN 
department,  and  the  BBN  program  manager  and  technical  director  realized  that  the 
GAMAT  system  could  be  used  to  provide  a  good  means  to  show  some  of  the 
capabilities  already  developed  in  the  ISQ  NOTAMs  system.  Under  a  BBN  Internal 
Research  &  Development  (IR&D)  effort  the  NOTAMs  system  was  integrated  with  the 
GAMAT  Global  Weather  Management  system  demonstrating  the  utility  of  a  simple 
reasoning  capability  to  tie  NOTAMs  to  missions  and  alerting  on  flight  safety  or  mission 
impacting  issues.  The  resulting  demonstration  of  linkage  of  the  two  systems  was 
shown  to  the  two  AFRL  program  managers  Edward  DePalma  (IFSA)  PM  for  the  IFM 
project  and  Sam  Kuper  (HECS)  PM  for  the  GAMAT  project.  The  results  were  sufficiently 
interesting  to  lead  to  demonstrations  of  the  combined  system  to  AMC  and  other  parts  of 
the  AF,  and  this  led  to  a  coordinated  effort  by  the  two  projects  and  the  two  AFRL 
directorates  (/IF  and  /FIE)  to  provide  a  more  robust  demonstration. 

The  MAF-CAF  demonstration  and  follow-on  work  (JEFX  ’04) 

This  demonstration  became  a  key  part  of  the  Hanscom  AFB  Electronic  Systems 
Command  (ESC)  Mobility  Air  Forces-Combat  Air  Forces  (MAF-CAF)  Global  Situation 
Awareness  initiative,  which  was  being  proposed  in  January  2003.  According  to  a 
summary  of  the  AMC-Air  Force  Materiel  Command  (AFMC)  Day  briefing  on  Feb  6, 
written  by  Dr.  Al  Graf  of  ESC/GA:  "Col  Al  Moseley,  ESC/GA  and  Col  Al  Baker, 
AMC/DOR  presented  a  summary  of  the  initiative  at  AFMC-AMC  Day  briefing  on  6  Feb. 
We  received  very  positive  feedback  from  AFMC/CC,  ESC/CC,  AMC/CV,  and  others  in 
attendance.  The  MAF-CAF  team  received  direct  support  for  the  demo  from  Gen  Lyles 
(Commander,  Air  Force  Materiel  Command),  who  offered  to  personally  brief  this  (and  its 
concept)  to  Corona  of  that  year.  He  also  offered,  based  on  some  comments  made  by  Lt 
Gen  Baker,  AMC/CV  to  introduce/sponsor  this  project  into  the  STRATCOM  CAF-MAF 
Working  Group  14  Feb,  as  well  as  the  MAF-CAF  Conference  in  late  March. 

Furthermore,  he  offered  O&M  funding  to  support  the  demo,  and  echoed  LtGen  Looney's 
(Commander,  Electronic  System  Center)  comment  that  we  should  engage  AFC2ISRC 
soonest  (Col  Paul  Curlette  (AFC2ISRC  Mobility  Liaison)  is  working  to  set  up 
briefings/discussions  with  MGen  Behler  and  appropriate  staff.)" 

The  net  result  of  this  was  that  much  of  our  work  in  the  first  year  was  demonstrated  as 
part  of  a  very  successful  CAF-MAF  interoperability  demonstration  at  ESC  and  Bolling 
AFB. 
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This  in  turn  led  to  a  successful  Engineering  Change  Proposal  to  extend  the  original 
contract  to  support  the  Global  Conops  Synchronization  demonstration  at  JEFX  2004. 

Further  contract  extensions 

Support  for  NGA 

The  initial  work  done  on  the  design  of  a  DARPA  Agent  Markup  Language  (DAML) 
ontology  for  NOTAMs  was  presented  at  the  DAML  Principal  Investigator  (PI)  meeting  in 
mid-October  2002.  The  result  of  this  presentation  was  an  invitation  to  present  our  work 
at  the  Semantic  Web  for  Military  Users  conference  in  April  2003.  This  led  to  a  contact 
with  David  White  of  the  National  Imagery  and  Mapping  Agency  (NIMA)  (now  NGA)  who 
indicated  that  he  thought  our  work  would  be  of  substantial  interest  to  the  NGA 
Aeronautical  group  in  St.  Louis.  He  made  a  contact  in  that  office,  and  we  arranged  to 
make  a  presentation  to  a  group  of  mid-level  managers  from  that  office. 

On  July  22,  2003  we  presented  a  two  hour  briefing  and  discussion  on  the  ISO 
NOTAMs  work  to  seven  senior  members  from  the  Saint  Louis  facility  of  NIMA,  office 
including  Lewin  M.  "Skip"  Ellis,  Deputy  Chief,  Aeronautical  Business  Office.  Also 
present  was  Greg  Padula  of  AMC  representing  the  project  at  the  behest  of  Edward 
DePalma  of  AFRL. 

This  was  followed  by  a  presentation  of  our  work  to  several  Senior  Executive  Service 
(SES)  level  personnel,  including  Lynn  Puetz,  SES,  Division  Chief  of  NGA  PN,  Tom 
Bowes,  deputy  Division  Chief,  Chuck  McGaugh,  SIS  who  supports  all  the  divisions  in 
NIMA  as  a  senior-level  technologist,  providing  valued  advice  and  opinions  on  new 
technologies  and  their  relevance  to  NGA.  This  meeting  was  also  attended  by  the  AFRL 
Mobility  ATD  lead  Edward  DePalma  (IFSA)  and  his  AFRL  branch  tech  advisor  Dan 
Fayette  (IFSA).  The  net  result  of  this  meeting  was  a  decision  by  NGA  to  initially  explore 
the  use  of  ISQ  NOTAMs  technology  in  support  of  the  NGA  Aeronautical  division,  and  to 
later  provide  a  prototype  operational  capability  for  supporting  the  operations  of  the  NGA 
Vertical  Obstructions  operation,  both  of  which  were  accomplished  by  funding  provided 
through  the  NOTAMs  contract  in  support  of  an  extension  to  the  original  contract 
providing  effort  to: 

•  Investigate  NGA's  Aeronautical  Safety  Division's  NOTAMs  practices  and  policies  to 
determine  any  required  upgrades  to  the  NOTAMs  ontology  and  system. 

•  Design,  develop  and  incorporate  into  the  NOTAMs  ontology  or  system  those 
upgrades  mutually  agreed  to  by  the  government  and  the  contractor. 

Install  and  support  the  upgraded  version  from  above  at  a  NGA  location  to  be  mutually 
agreed  to  by  the  government  and  the  contractor  for  test,  feedback,  modification  and 
reinstall  purposes. 

Exploratory  technical  efforts: 

The  contract  was  further  extended  to  support  the  following  exploratory  technical 
efforts: 

1 )  Knowledge  representation  development: 

-  Extend  the  NOTAMs  ontology  to  describe  a  set  of  critical 

resources/facilities/capabilities  reported  on  by  NOTAMs  and  the  changes 
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and  impacts  on  those  resources  due  to  the  information  contained  within 
NOTAMs. 

-  Populate  a  knowledge  base  represented  in  terms  of  the  above  resource 
ontology  for  a  critical  set  of  resources  based  on  available  government 
and/or  commercial  data  sources  to  create  a  specific  instance  knowledge 
base.  Develop  automated  tools  to  populate  and  update  the  resource 
knowledge  base. 

-  Develop  tools  to  modify/update  the  resource  knowledge  base  based  on 
Web  Ontology  Language  (OWL)-an notated  NOTAMs. 

2)  Intelligent  Access/Retrieval  Query  Mechanism 

-  Design  an  intelligent  (inference-based)  mechanism  to  permit  other 
systems  to  access  and  retrieve  task-focused  resource  and  NOTAMs 
knowledge  from  the  expanded  knowledge  base. 

Develop  prototype  intelligent  access  and  retrieval  tools  to  demonstrate  the 
mechanism  designed  above. 
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Methods,  Assumptions,  and  Procedures 

Limitations  on  technology  imposed  by  input  data  problems  and  air 
safety  considerations 

As  the  project  developed  it  became  clear  that: 

•  It  would  be  possible  to  effectively  extend  and  apply  existing  natural  language  and 
knowledge  representation  techniques  to  extract  much  of  the  critical  information 
content  for  a  large  class  of  NOTAMs. 

•  The  breadth  of  material  covered  in  NOTAMs  was  much  broader  than  initially 
expected,  and  the  actual  NOTAM  text  was  full  of  human  errors  ranging  from 
misspellings,  to  mangled  grammar,  to  clearly  incorrect  specifications  of  changes  in 
the  aeronautical  environment. 

This  led  to  an  important  caveat,  accepted  by  the  government  as  part  of  requirements 
document  for  the  system  to  be  produced: 

ISO  NOTAMs  is  a  prototype  system.  It  is  not  designed  to  be  placed  in  operational 
use,  but  is  intended  to  demonstrate  the  capabilities  of  current  natural  language 
processing  and  knowledge  representation  in  the  context  of  future  AMC  systems.  The 
goal  of  ISO  NOTAMs  is  to  increase  the  ability  to  automate  the  overall  NOTAM 
distribution  and  decision  making  system,  without  compromising  safety.  The  ISO 
NOTAMs  system  will  never  change  the  content  of  a  NOTAM,  but  will  only  add 
additional  machine  understandable  annotations  to  a  record  describing  the  NOTAM. 
Systems  that  make  use  of  the  output  of  ISQ  NOTAMs  should  exercise  great 
care  in  filtering  out  NOTAMs  based  on  the  contents  of  annotations  -  perhaps 
only  using  issuing  location  and  official  time  stamps  for  such  filters.  All  other 
operations  should  be  in  the  form  of  highlighting  and  organizing  sets  of 
NOTAMs  to  make  it  easier  for  planners,  FMs  and  flight  crews  to  quickly  find  the 
relevant  critical  NOTAMs  for  each  phase  of  planning,  monitoring  and  execution  of  a 
mission. 

Because  of  the  uncontrolled  nature  of  the  NOTAM  text,  and  the  likelihood 
that  new  reportable  situations  and  variant  ways  of  reporting  such  situations  (as 
well  as  human  error  in  entering  NOTAMs)  we  do  not  expect  that  fully 
automated  annotation  systems  will  be  feasible  in  the  near  term.  Thus,  the  initial 
output  of  the  ISQ  NOTAMs  must  be  reviewed  for  possible  error.  A  human  will 
be  incorporated  in  the  annotation  loop,  with  software  interfaces  designed  to 
substantially  reduce  the  cost  of  such  human  supervisory  control  in  the 
annotation  process 

.While  extensions  and  follow-ons  to  the  NOTAMs  contract  have  included  producing 
initial  operational  capabilities  as  part  of  the  JMPS  system,  it  is  important  to  note  that  the 
spirit  of  this  caveat  still  holds.  In  the  foreseeable  future,  no  fully  automated  system  will 
be  able  to  extract  information  from  all  NOTAMs,  nor  will  such  a  system  be  able  to 
produce  completely  error-free  results  as  long  as  the  input  NOTAM  stream  contains  as 
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much  dirty  data  as  has  been  seen  in  the  past  several  years  of  monitoring  and  parsing 
this  input.  Thus  any  operational  system  that  uses  this  technology  must  be  designed  to 
use  it  in  such  a  way  as  to  improve  the  operation  of  the  existing  human-centered 
approach  to  finding  NOTAMs  relevant  to  given  missions,  never  reducing  or  modifying 
the  information  currently  presented  to  flight  managers  and  aircrews,  but  primarily 
focusing  on  improving  the  situational  awareness  and  effectiveness  of  flight  managers 
and  aircrews  by  highlighting  critical  information  contained  in  NOTAMs.  The  goal  of  the 
resulting  systems  must  be  to  increase  ability  to  automate  parts  of  the  NOTAMs 
utilization  process,  without  compromising  safety  -  it  must  keep  a  human  in  the 
loop,  and  the  human  must  be  responsible  for  all  flight  safety  decisions. 

As  this  program  proceeded  we  learned  many  things  that  suggest  profitable  future 
areas  of  research  and  development  for  the  Air  Force.  The  ISO  NOTAMs  project  is  just 
the  tip  of  the  iceberg  in  what  can  be  done  by  appropriate  application  of  parsing  and 
knowledge  representation  problems  to  Air  Force  problems.  The  initial  statement  of  work 
of  this  project  indicated  that  the  resulting  system  would  parse  and  extract  a  limited 
number  of  critical  pieces  of  information  content  from  NOTAMs  -  the  final  result  was 
much  broader  than  initially  conceived.  However,  it  has  become  clear  as  we  reviewed 
the  results  in  parsing  over  three  million  NOTAMS,  that  there  are  important  pieces  of 
information  that  would  be  of  value  to  the  Air  Force  and  others  that  could  be  extracted 
from  NOTAMs,  and  that  the  accuracy  and  robustness  of  the  output  of  the  system  can  be 
improved.  There  are  both  incremental  changes  and  major  extensions  that  could  (and 
should)  be  applied  to  this  and  related  problems.  There  are  changes  and  extensions  to 
the  grammar  used  by  the  parser  that  would  make  significant  improvements  in  coverage 
(types  of  information  extracted),  accuracy  and  robustness  (resistance  to  common  and 
rare  errors  found  in  NOTAMS). 

In  terms  of  incremental  changes,  we  estimate  that  six  to  twelve  person  months  of 
effort  on  the  grammar  should  cut  in  half  the  gaps  in  coverage  and  error  rate  in  parsing. 
This  effort  would  be  enhanced  by  supporting  active  participation  of  domain  experts 
(pilots,  flight  managers)  in  helping  the  computer  scientists  understand  the  content  of 
NOTAMs.  Experience  has  shown  that  while  the  majority  of  NOTAMs  are  readily 
understandable  after  background  reading,  there  are  a  surprising  number  of  NOTAMs 
that  leave  the  developers  scratching  their  heads  and  searching  for  information  sources 
to  explain  them,  and  the  ability  to  quickly  get  authoritative  interpretations  of  these 
NOTAMs  would  substantially  increase  productivity. 

Additionally,  there  is  an  ongoing  effort  by  EUROCONTROL  and  the  FAA  (and  more 
recently  ICAO)  to  develop  XNOTAM  which  is  a  standardized  XML  format  for  issuing 
machine-interpretable  NOTAMs.  The  definition  of  XNOTAM  is  now  scheduled  to  be 
produced  in  2007.  The  utility  of  the  current  ISO  NOTAMs  capability  would  be  increased 
by  making  sure  that  its  OWL  representation  can  be  readily  inter-translated  with  the 
XNOTAM  notation,  so  that  systems  can  make  use  of  both  types  of  information.  This 
could  be  achieved  by  retrofitting  an  XNOTAM  based  tag  space  to  the  ISO  NOTAMs 
system,  and  if  possible  by  supporting  collaboration  to  make  the  existing  OWL  NOTAMs 
part  of  the  design  for  XNOTAMs. 
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Larger  scale  changes  that  are  obvious  at  this  point  are  the  ability  to  interpret  the  use 
of  two  dimensional  (tabular)  formatting  in  NOTAMs,  and  the  incorporation  of  reasoning 
based  on  aeronautical  knowledge  basis  such  as  DAFIF  (the  Digital  Aeronautical  Flight 
Information  File)  directly  into  the  parsing  process. 

Tabular  formats  are  not  typically  addressed  by  computational  linguistic  systems,  and 
the  original  NOTAMs  source  provided  to  us  was  discovered  (at  the  end  of  the  project)  to 
have  automatically  replaced  all  line-feeds  with  spaces,  thus  totally  destroying  the  two 
dimensional  formatting  carefully  inserted  by  human  NOTAM  entry.  When  the  original 
NOTAM  format  was  provided  to  us  as  part  of  the  FAA  support  of  the  JMPS  program,  it 
became  clear  how  much  information  could  be  obtained  from  this  formatting,  and  how 
many  seemingly  intractable  parsing  problems  (phrases  whose  meaning  were  not  readily 
interpretable  from  the  linear  sequence  of  words)  were  substantially  clarified  (to  the 
human  eye,  at  least)  by  restoring  the  formatting.  There  is  very  little  currently  available 
technology  to  deal  with  parsing  such  two  dimensional  formats,  and  both  research  and 
development  is  needed  -  the  net  result  would  be  substantially  improved  parsing  of  the 
10-20%  of  NOTAMs  that  use  such  formatting  in  a  critical  manner. 

There  are  many  cases  of  ambiguity  and  error  in  NOTAMs  that  are  typically  resolved 
by  human  readers  (e.g.  pilots)  using  commonsense  reasoning.  Thus,  for  example,  “this 
NOTAM  was  issued  by  Germany,  and  there  is  a  latitude/longitude  pair  in  the  middle  of 
an  airspace  description  that  is  in  Zimbabwe  -  this  is  probably  a  typographical  error”, 
“LEGAL  is  the  name  of  a  waypoint,  but  in  the  context  of  the  phrase  LEGAL 
REQUIREMENTS  it  is  probably  not  a  reference  to  that  waypoint”,  or  “this  Belgian 
NOTAM  mentions  a  navaid  designator  in  use  in  the  US,  Australia  and  Belgium  -  the 
most  likely  interpretation  is  the  Belgian  navaid.  Some  rudimentary  forms  of  this 
reasoning  are  incorporated  in  the  current  system  as  post-processes  to  parsing  and  they 
were  added  after  the  fact  to  solve  particular  problems.  Sometimes  this  post-processing 
is  too  late  -  the  parser  was  forced  to  make  a  decision,  and  alternative  interpretations 
are  discarded  within  the  parsing  process,  making  it  impossible  to  correct  by  later 
reasoning.  A  more  thorough  integration  of  reasoning  early  in  the  parsing  process  would 
seem  to  be  the  right  approach  to  handling  these  problems  (though  other  approaches 
should  also  be  investigated). 

Finally,  although  we  have  continually  tried  to  assess  the  performance  of  the  current 
system,  and  have  developed  many  tools  to  do  so,  there  is  critical  work  to  be  done  in  the 
specification  of  formal  performance  requirements  for  such  a  system,  in  terms  of 
accuracy  and  completeness  of  its  parses  and  the  resulting  characterization  of  NOTAMs. 
As  mentioned,  the  characteristics  of  NOTAMs  as  human  entered  text  makes  perfect 
parsing  an  unattainable  goal  -  the  critical  issue  is  to  determine  how  good  is  good 
enough  (what  can  be  done  to  reduce  the  workload  of  flight  personnel,  and  increase  their 
situational  awareness  while  increasing,  or  at  least  not  compromising,  flight  safety). 


Design  requirements 

As  a  result  of  discussions  with  AFRL  and  AMC  personnel,  it  was  decided  that  there 
were  a  number  of  requirements  that  had  to  be  met  by  the  resulting  system.  It  must: 
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•  Increase  the  ability  to  automate  the  NOTAMs  process  without  compromising  safety  - 

•  Must  keep  a  human  in  the  loop 

•  Provide  human  supervisory  control  in  the  annotation  process 

•  Provide  machine  understandable  representations  of  selected  NOTAM  content  to  be 
used  by  other  applications, 

•  The  appropriate  type  of  information  to  be  extracted  from  NOTAMs  depends  on 
the  planned  downstream  applications 

•  Be  a  reusable  and  modular  component  that  can  be  readily  integrated  into  a  number 
of  potential  systems 

•  Use  current  web  technologies  to  build  a  component  which  can  be  readily 
integrated  into  a  NOTAM  distribution  system  (not  build  a  distribution  system) 

Operate  within  the  constraints  of  the  existing  AF  and  DINS  established  NOTAMs 
system.  It  must  obtain  NOTAMs  from  an  official  source,  and  it  is  not  allowed  to  modify 
the  original  NOTAMs. 

Overall  architecture 

In  order  to  satisfy  these  design  requirements,  we  developed  the  following  architecture, 
which  has  been  maintained  with  minor  variations  up  until  the  time  we  started  direct 
implementation  of  a  JMPS  version  of  the  system.  The  system  architecture  designed  to 
meet  these  requirements  is  shown  in  Figure  6. 
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OWL-NOTAMS  System  Architecture 


•Can  operate  from  any  feed  of  NOTAM  information. 

•Provides  access  to  annotated  NOTAMs  as  a  web-service 

•Also  provides  access  through  direct  SQL  queries,  file  transfers  (FTP  or  SCP). 

•Eventually  semantic  queries  (OWL  query  language). 


Figure  6:  The  OWL-NOTAMS  System  Architecture 

It  was  discovered  early  in  the  project  that  there  was  an  existing  Extensible  Markup 
Language  (XML)  formatted  web-accessible  official  source  of  NOTAMs  being  used  by 
AMC  -  the  AMC  NOTAM  cache.  The  fact  that  the  AMC  NOTAM  cache  used  XML  and 
web  services  made  the  architectural  decision  straightforward.  We  had  already  intended 
to  represent  the  information  content  of  NOTAMs  in  DAML+OIL,  an  XML  ontology  sub¬ 
language.  We  also  planned  to  provide  this  information  in  the  form  of  annotations 
attached  to  the  original  NOTAMs.  Since  it  is  technically  simple  to  add  new  XML 
formatted  fields  to  an  existing  XML  document,  we  decided  that  in  order  to  provide 
maximum  flexibility,  the  system  was  designed  as  a  middleware  XML  web-based 
process.  The  initial  system  would  obtain  each  NOTAM  from  the  AMC  NOTAM  cache, 
apply  appropriate  natural  language  techniques  to  extract  critical  information  from  the 
NOTAM,  represent  that  information  in  XML  (as  a  DAML+OIL  annotation)  and  produce 
an  extended  form  of  the  original  NOTAM,  containing  all  the  original  XML  fields,  plus  one 
new  field  that  held  the  DAML+OIL  annotation.  Additionally,  to  support  continued 
development  and  testing  of  the  system  as  the  set  of  active  NOTAMs  changed  over  time, 
we  would  maintain  a  complete  local  store  of  NOTAMs,  mirroring  the  history  of  NOTAMs 
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available  from  the  AMC  cache.  We  would  also  provide  a  web-interface  that  was 
identical  in  form  to  the  AMC  NOTAM  cache,  so  that: 

•  any  legacy  system  which  could  retrieve  NOTAMs  from  the  cache  would  be  able  to 
access  the  ISQ  NOTAM  cache  and  use  the  output  as  a  replacement  for  the  AMC 
cache  simply  by  ignoring  the  added  field 

•  any  system  that  wished  to  make  use  of  the  new  information  provided  the  annotated 
NOTAMs  could  retrieve  them  in  the  same  way  as  a  legacy  system 

Within  the  first  month  of  the  project  we  had  implemented  a  system  to  pull  all 
NOTAMs  from  the  AMC  cache  and  populate  an  ever-growing  local  store  of  NOTAMs. 
We  have  used  this  store  over  the  life  of  the  project,  testing  new  versions  of  our  system 
not  only  on  the  current  active  NOTAMs,  but  also  on  large  sets  of  historical  NOTAMs.  To 
date  we  have  processed  over  4,000,000  NOTAMs. 

Key  technical  problems  addressed  by  the  project 

In  order  to  understand  the  problems  to  be  addressed  by  this  project  we  examine  the 
difficulties  faced  by  two  suggested  alternative  approaches  to  the  problem  of  alerting 
FMs  to  critical  NOTAMs. 

Option  1  -  Why  not  simply  use  Q-codes? 

The  first  approach  makes  use  of  Q-codes,  five-character  internationally  standardized 
codes  that  are  intended  to  represent  the  critical  information  content  of  NOTAMS.  To 
quote  the  appendix  of  Federal  Aviation  Order  7930.2,  Notices  to  Airmen,  Q-codes  are 
defined  as  follows: 

a.  A  NOTAM  code  group  contains  five  letters.  The  first  letter  is  always  the  letter 
"Q"  to  indicate  a  code  abbreviation  for  use  in  the  composition  of  NOTAMs. 

b.  The  second  and  third  letters  identify  the  subject  being  reported.  (See  Second 
and  Third  Letter  Decode  Tables  in  section  0). 

c.  The  fourth  and  fifth  letters  identify  the  status  of  operation  of  the  subject  being 
reported.  (See  Fourth  and  Fifth  Letter  Decode  Tables  in  section  0). 

Thus,  a  NOTAM  containing  the  Q-code  QMRLC  can  be  decoded  as  meaning 
“runway  closed”  based  on  Q  (indicating  a  Q-code)  M  (movement  area)  R  (runway)  LC 
(closed). 

The  majority  of  international  NOTAMs  and  US  military  NOTAMs  contain  Q-codes. 
Unfortunately  Q-codes  do  not  provide  an  adequate  solution  to  the  problem  posed  by 
AFRL  and  AMC,  because: 

•  Not  all  NOTAMs  contain  Q-codes 

o  In  particular,  US  domestic  NOTAMs  almost  never  contain  Q-codes 

•  Q-codes  provide  incomplete  information  for  decision  making,  e.g. 

o  Given  a  QMRLC  NOTAM,  it  is  critical  to  know  what  runway  is  actually  closed 
o  For  a  QRACA  NOTAM,  it  is  critical  to  know  the  geo-spatial  bounds  of  the  area 
reserved 

o  For  a  QP  NOTAM  it  is  critical  to  know  which  procedure  is  being  affected 
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•  Many  Q-codes  that  show  up  in  actual  NOTAMs  are  incomplete  or  inaccurate 
o  In  a  large  sample  of  US  military  and  international  NOTAMS  taken  early  in  the 
ISQ  NOTAMs  project,  approximately  1/3  had  QXXXX  as  the  Q-code  -  this 
wildcard  Q-code  has  no  explicit  meaning,  and  is  intended  to  be  used  only  for 
cases  not  covered  by  other  Q-codes.  In  fact,  the  text  of  a  very  large  number  of 
the  QXXXX  cases  is  completely  consistent  with  a  more  informative  Q-code 

Thus,  a  system  built  on  Q-codes  will  not  be  able  to  correctly  categorize  a  very  large 
number  of  NOTAMS,  and  will  be  unable  to  obtain  critical  information  from  much  of  the 
remainder 

Option  2  -  Why  not  use  keyword  search  on  the  text  block? 

The  IMT  system  attempts  to  aid  FMs  in  discovering  critical  NOTAMs  by  doing  simple 
keyword  search  in  the  NOTAM  text  block.  Unfortunately,  not  only  is  the  method  unable 
to  obtain  critical  information  such  as  the  boundaries  of  special  use  airspace,  but  it  is 
also  reported  by  FMs  to  produce  an  unacceptably  high  number  of  “false  alarms”  (some 
FMs  have  said  that  using  this  feature  has  a  tendency  to  “turn  the  entire  NOTAM  screen 
red”).  Why  is  this?  Consider  a  simple  case  -  FMs  must  be  aware  of  all  runway  closures 
that  affect  aerodromes  of  current  interest,  as  well  as  all  closures  of  the  aerodromes 
themselves.  The  text  string  CLOSED2  (and  a  few  variants  such  as  CLSD)  is  a  common 
indicator  for  runway  and  airport  closures.  Using  this  as  a  search  term  provides  many 
false  alarms  because  many  other  things  can  be  closed  as  shown  in  the  following 
NOTAMs: 

ZGNN\ NANNING/WUXU\A0484/04  ...  E)  TWY 4  CLSD 

MMCS\ CIUDAD  JUAREZ\A1 355/04  ...  E)  TURNING  BAY  THR  RWY  03 

MROC\ALAJUELA/JUAN  SANTAMARIA  INTL.\A0454/04  ...  E)  ACFT  STAND  NR 
09  CLSD 

EPWW\  WARSZA WA/A CC\A2257/04  ...  E)  ATS  ROUTE  R236  BTN  VAVEL-LENOV 
FM  FL065  UP  TO  FL085  CLSD 

Even  slightly  more  complex  patterns  do  not  function  well,  so  the  pattern 
RWY... CLSD  will  pick  up  the  following  NOTAM: 

LIPH\TREVISO/S.ANGELO\M1310/04  ...  E)  1ST  AND  3RD  MIL  TWY  RIGHT  SIDE 
RWY07  CLSD 

In  order  to  go  beyond  these  two  approaches  we  needed  to  make  the  critical 
information  contained  in  the  NOTAM  text  block  (already  a  “machine  readable”  form)  into 
something  that  a  machine  could  reason  on  and  display  in  various  forms  (a  “machine 
understandable”  representation).  Graphically,  using  an  annotated  screen  shot  from  a 
running  ISQ  NOTAMs  system,  our  goal  was  to  support  the  following  process: 


2  To  give  a  slight  idea  of  the  actual  types  of  variations  we  have  seen  in  NOTAMs,  the  ways  that  closure  can  be 
represented  in  NOTAM  text  includes:  CLSD,  CLOSED,  DCMSND,  CLOSURE,  DECOMMISSIONED,  WILL  BE 
CLOSED,  IS  CLOSED,  DEACTIVATED,  ARE  CLOSED,  DCMSN,  IS  CLSD,  REMAIN  CLSD,  WITHDRAWN 
FROM  SERVICE,  COMPLETELY  WITHDRAWN  FROM  SERVICE,  CLOSD,  FERME,  FERMEE,  WILL  BE 
WITHDRAWN  FROM  SERVICE,  CLS,  CLSDS,  CLSED,  CLOSING,  COLSED,  FERMETURE, 
DESACTIVADO. 
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Figure  7:  The  process  of  bringing  free-form  NOT AMs  text  to  machine-understandable  representation 

This  posed  two  problems: 

Problem  1:  We  needed  to  represent  the  complex  real-world  structure  of  the  critical 
information  expressed  by  NOTAMs 

Solution:  Knowledge  Representation  Technology  (in  particular,  semantic  web 
technology) 

Problem  2:  We  needed  to  recognize  and  interpret  complex  structured  patterns  in 
NOTAM  text  that  encoded  the  critical  information 
Solution:  Language  Processing  (Parsing  technology) 

Parsing 

The  original  concept  for  the  parsing  engine  of  the  ISQ  NOTAMs  project  was  to  build  on 
BBN’s  substantial  experience  in  building  natural  language  parsers,  particularly 
leveraging  recent  work  on  high  accuracy  statistical  parsers  for  English.  This  seemed 
reasonable  since  documentation  on  NOTAMs  indicated  that  by  ICAO  standards, 
NOTAMs  were  supposed  to  be  issued  in  English,  the  standard  international  language 
for  flight  safety.  In  the  early  stages  of  the  project,  we  performed  an  analysis  of  tens  of 
thousands  of  actual  NOTAMs  and  discovered  that  the  “English”  of  NOTAMs  was  not  the 
same  as  the  English  we  had  developed  tools  to  parse.  We  discovered  that  NOTAMs 
text  was  not  uniform  but  in  fact  had  quite  a  range. 
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From  simple  but  cryptic: 

•  A)  CYYT  B)  0302141922  C)  0302151530  E)  ILS  GP  29  U/S 

•  MIA\MIAMI  INTL\MIA  02/140  MIA  30  ILS  OTS  WEF  0502241000 
•  22  ILS  OM  OTS  WEF  0302041800-0302042200 

•  TOWER  1099  (499  AGL)  11  S  LGTS  OTS  TIL  0302251611 

•  1 7L/35R  PTCHY  THN IR/SLR  ON  EDGES  WEF  0302182328 


To  somewhat  more  complex: 

•  ZJX\JACKSONVILLE  (ARTCC),FL.\CARF  03/009  ZJX  STATIONARY 
ALTITUDE  RESERVATION  WITHIN  AN  AREA  DESCRIBED  AS  SZW182042 
TO  SZW161049  TO  SZW160055  TO  SZW196053  TO  POINT  OF 
BEGINNING.  AVOIDANCE  ADVISED.  5000-17999  WEF  0503021 330- 

0503030145 

To  legalistic  and  complex: 

•  LGGG\ATHINAI  (A CC, FIC, FIR, UIR)\A23 79/04  NOTAMN  Q) 
LGGG/QWEL  W/IV/BO/W/OOO/999  A)  LGGG  PART  1  OF  2  B)  0501030500  C) 
0503311300  E)  NAVIGATIONAL  WARNING  TO  ALL  CONCERNED:  THIS 
NOT  AM  IS  ISSUED  TO  STATE  THAT  THE  TURKISH  NOT  AM  A3019/04 
LTAAYNYX  IS  NULL  AND  VOID  SINCE  IT  REFERS  TO  TURKISH 
MILITARY  ACTIVITIES  WITHIN  ATHINAI  FIR  WHERE  THE  ONLY 
COMPETENT  AUTHORITY  TO  PROMULGATE  NOTAMS  IN 
ACCORDANCE  WITH  ICAO  RULES  AND  REGULATIONS  IS  THE 
HELLENIC  CIVIL  AVIATION  AUTHORITY  THROUGH  ITS  APPROPRIATE 
AIS  UNIT  AND  THE  ONLY  RESPONSIBLE  AUTHORITY  FOR  THE  SAFETY 
OF  THE  AIR  TRAFFIC  IS  THE  HELLENIC  CAA  THROUGH  THE  ATS 
UNITS.  FURTHERMNORE  GREECE  HAS  ALREADY  ADVISED  TURKEY 
BY  COORDINATION  MESSAGES  271230  AND  291236  LGACYAYC  THAT 
THE  MENTIONED  EXERCISE  AREA  DEFINED  BY  COORDINATES 
401630N253900E,  401800N253000E,  403500N245800E,  401100N243300E, 
400900N244500E,  402000N245600E,  400700N253300E  OVERLAPS  AREA 
OF  NATIONAL  SOVEREIGNTY  OF  GREECE  AND  CONSEQUENTLY  IT  IS 
NOT  AVAILABLE.  THE  SAID  AREA  ALSO  OVERLAPS  PART  OF  LIMNOS 

TMA. 
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Further  analysis  showed  demonstrated  that  NOTAM  text  was  in  fact  not  English,  but 
a  highly  specialized  sub-language  with  special  vocabulary  and  syntax  that  is 
characterized  by  high  variability,  embedding3,  a  lack  of  recursion,  and  few 
constraints  on  word  order.  In  fact,  NOTAMs  seem  to  be  closer  to  what  linguists  term 
a  “pidgin”  than  a  natural  language  -  this  is  not  surprising,  since  the  context  in  which 
NOTAMs  are  issued  is  a  classical  context  for  the  formation  of  a  pidgin.  (A  Pidgin,  or 
contact  language,  is  the  name  given  to  any  language  created,  usually  spontaneously, 
out  of  a  mixture  of  other  languages  as  a  means  of  communication  between  speakers  of 
different  tongues.)  NOTAMs  are  produced  in  a  primarily  free  text  form  by  over  6,000 
individual  airfields  and  air  traffic  control  centers  in  160  countries  around  the  world.  Thus, 
NOTAMs  represent  an  attempt  at  communication  by  a  group  of  people  who  do  not 
share  a  common  native  language  (given  that  they  are  issued  by  160  countries). 

In  addition  NOTAM  vocabulary  is  a  highly  technical  and  abbreviated  variant  of 
English,  for  the  most  part,  with  substantial  numbers  of  abbreviations  and  jargon-like 
phrases  (as  well  as  1-2%  of  French  and  Spanish  NOTAMs,  and  even  the  odd 
Czechoslovakian  NOTAM).  Additionally,  even  when  considered  as  a  pidgin,  NOTAMs 
contain  plentiful  misspellings,  many  obvious  errors,  and  wide  variation  in  ways  of 
expressing  even  very  common  content  such  as  time  and  duration  phrases,  locations 
and  even  standard  safety  equipment.  Despite  attempts  at  standardization  both 
nationally  and  internationally  there  is  multiple  national  standards  for  NOTAM  report 
formats,  and  such  standards  are  commonly  breached.  The  majority  of  NOTAMS  are 
manually  input,  NOTAM  text  uses  a  highly  abbreviated  flight  domain  language; 
misspellings  are  common,  sentences  are  fragmented,  punctuation  is  applied 
haphazardly,  and  ambiguities  and  errors  occur  in  many  NOTAMs. 

We  initially  planned  on  modifying  BBN’s  trainable  context  free  parsing  system  to 
handle  NOTAMs,  but  it  became  clear  that  this  approach  had  problems.  Since  NOTAM 
text  was  clearly  so  far  from  the  type  of  English  that  the  system  had  been  trained  for,  we 
would  not  simply  be  adding  to  the  training  set  and  getting  reasonable  results.  It  would 
be  necessary  to  provide  hand-built  annotation  for  a  large  body  of  NOTAMs.  In  the  case 
of  other  natural  languages,  we  have  been  able  to  do  this  at  reasonable  expense 
because  it  was  usually  possible  to  find  native  speakers  of  the  language  in  the  local 
college  population,  and  to  hire  them  to  annotate  a  body  of  text.  It  was  not  at  all  clear 
what  the  equivalent  would  be  for  the  international  set  of  NOTAMs.  Typically,  most 
people  who  have  learned  to  read  NOTAMs  are  licensed  pilots.  At  the  very  least,  we 
would  have  to  find  a  set  of  trained  pilots  to  use  for  the  annotation,  and  the  cost  would 
likely  exceed  our  budget.  Additionally,  while  such  pilots  might  be  able  to  understand 
NOTAMs  so  that  they  can  fly  safely,  they  would  have  to  be  trained  themselves  to 
understand  the  type  of  structures  needed  to  annotate  the  NOTAMs.  One  additional 


3  Embedding,  in  this  context,  is  the  construction  of  phrases  from  smaller  phrases  such  as  PRECISION  APPROACH 
LIGHTS  RWY  27  OTS  which  is  made  up  of  “PRECISION  APPROACH  LIGHTS”,  “RWY  27”  and  “OTS”  (out  of 
service).  Recursion  is  embedding  in  which  the  contained  phrase  is  of  the  same  type  (though  not  identical)  to  the 
containing  phrase,  as  in  the  English  “the  man  who  was  seen  talking  to  a  young  woman”  in  which  “the  man”  and 
“young  woman”  are  both  noun  phrases,  and  this  can  be  extended  to  “the  man  who  was  seen  talking  to  the  young 
woman  who  was  carrying  a  child  who  was  giggling.” 
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major  factor  appeared  -  speed  of  parsing.  While  the  operational  NOTAMs  system  would 
have  moderate  processing  constraints  (hundreds  of  NOTAMs/hour)  the  development 
phase  would  require  very  fast  processing.  It  would  be  important  to  be  able  to 
understand  the  linguistic  patterns  in  very  large  groups  of  NOTAMs  (tens  of  thousands  of 
NOTAMs).  Additionally,  when  considered  as  “sentences”  very  many  NOTAMs  had 
extremely  large  numbers  of  words. 

Existing  natural  language  parsers  could  not  parse  the  hundred  or  more  tokens  that 
make  up  a  single  NOTAM  in  under  a  second,  and  we  needed  to  parse  many  NOTAMs 
per  second. 

In  order  to  deal  with  these  problems,  and  given  that  our  goal  was  to  extract  critical 
information  from  NOTAMs,  but  not  necessarily  provide  complete  parses  for  them,  we 
decided  to  look  at  approaches  other  than  variants  of  context  free  parsing.  The  parsing 
approach  and  rule  set  we  chose  are  targeted  to  the  observed  characteristics  of  the 
NOTAMs  language. 

NOTAMs  text  is: 

•  Specialized,  complex  but  not  recursive  like  more  general  natural  languages  such 
as  English 

•  NOTAMs  typically  consist  of  sets  of  hierarchical  phrases,  with  far  fewer  phrase 
order  constraints  than  English. 

After  considering  these  features,  and  the  need  for  high  efficiency,  we  decided  to  use 
an  approach  which  had  been  demonstrated  to  produce  good  results  in  a  variety  of 
information  extraction  problems.  We  built  our  parser  as  a  cascade  of  finite  state 
transducers.  To  quote  a  paper  on  the  subject:  “Finite-state  cascades  represent  an 
attractive  architecture  for  parsing  unrestricted  text.  Deterministic  parsers  specified  by 
finite-state  cascades  are  fast  and  reliable.  They  can  be  extended  at  modest  cost  to 
construct  parse  trees  with  finite  feature  structures.  Finally,  such  deterministic  parsers  do 
not  necessarily  involve  trading  off  accuracy  against  speed — they  may  in  fact  be  more 
accurate  than  exhaustive-search  stochastic  context  free  parsers.”  (Steven  Abney.  1996. 
Partial  parsing  via  finite-state  cascades.  In  Workshop  on  Robust  Parsing,  8th  European  Summer  School 
in  Logic,  Language  and  Information,  Prague,  Czech  Republic,  pages  8--15.) 

In  order  to  pursue  this  approach  we  first  experimented  with  an  existing  finite  state 
cascade  (GATE  -  a  General  Architecture  for  Text  Engineering).  This  showed  that  the 
approach  was  feasible,  but  the  GATE  parser  was  far  too  slow  for  our  purposes,  and  had 
serious  restrictions  on  the  types  of  semantic  output.  Thus,  we  developed  the  FIST 
(Finite  State  Transducer)  system,  an  extremely  efficient  implementation  of  a  cascaded 
finite  state  analyzer.  FIST  is  implemented  on  top  of  Java,  with  the  key  recognition  phase 
being  done  using  a  Java  implementation  of  a  finite  state  processor  built  on  networks  of 
hash-coded  dispatch  tables.  The  process  of  “semantic  interpretation”  of  the  resulting 
phrases  is  written  in  JScheme,  which  is  a  version  of  the  Scheme  programming 
language  implemented  in  Java,  and  which  provides  efficient  and  perspicuous  access  to 
all  aspects  of  programs  written  in  Java,  including  all  of  the  Java  libraries.  The  FIST 
parser  is  FAST,  and  it  can  readily  integrate  large-scale  specialized  dictionaries  (e.g. 
complete  DAFIF  special  use  airspace,  navaid  and  waypoint  data).  Versions  of  FIST 
with  an  initial  moderate  size  cascade  (fifty  rules)  parsed  30  NOTAMs  per  second  on  a 
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standard  desktop  PC,  and  the  most  recent  (and  substantially  more  complex)  version  of 
the  system  with  several  hundred  rules  still  parses  more  than  5  NOTAMs  per  second. 

Ontology 

As  part  of  the  project  design  we  planned  to  represent  the  critical  information  content  of 
each  NOTAM  as  an  XML  annotation  within  the  XML  structure  for  the  NOTAM.  The  goal 
was  to  use  the  most  expressive  standardized  representation  available.  The  decision 
was  made  to  use  an  “ontological”  language,  and  to  choose  such  a  language  which  was 
compatible  with  XML. 

An  ontology  is  a  data  model  that  represents  a  domain  and  is  used  to  reason 
about  the  objects  in  that  domain  and  the  relations  between  them.  Ontologies  are 
used  in  artificial  intelligence,  the  semantic  web,  and  software  engineering  as  a 
form  of  knowledge  representation  about  the  world  or  some  part  of  it. 

At  the  start  of  the  project  the  best  choice  of  representation  appeared  to  be  the 
DAML+OIL  standard  established  by  a  joint  US/EU  commission,  based  on  the  DARPA 
DAML  language  and  the  European  OIL  language. 

Some  early  responses  to  our  design  decision  raised  the  question  as  to  why  we  used 
an  ontology  language,  rather  than  using  “straight  XML.”  It  is  important  to  realize  that 
DAML+OIL  annotations  are  in  fact  well-formed  XML  -  it  is  just  that  DAML+OIL  has  a 
well  defined  semantics,  not  simply  a  well-defined  structured  syntax.  Another  suggestion 
was  to  use  a  semantic  extension  of  XML  called  the  Resource  Description  Framework 
(RDF).  In  fact,  DAML+OIL  is  an  extension  of  (and  compatible  with)  RDF.  The 
distinctions  between  XML,  RDF  and  DAML+OIL  can  be  summarized  as  follows: 

•  XML  is  the  universal  format  for  structured  documents  and  data  on  the  Web,  but: 

o  [SGML  and  ]XML  are  meta-language  facilities  for  defining  markup 
languages,  [which]  declare  formal  features  for  syntax,  but  have  no 
mechanisms  for  formally  expressing  semantics.  SGML  parsers  and  XML 
processors  do  not  know  what  is  meant  by  the  natural  language  labels 
(element  type  names,  attribute  names),  nor  what  may  be  implied  by  the 
instance  hierarchy;  ...  In  SGML  and  XML,  semantics  can  be  expressed 
only  informally  (e.g.,  in  comments). 
(http://xml.coverpages.org/semantics.html) 

•  RDF  is  a  language  written  with  XML  syntax  that  adds  the  following  features: 

o  machine  understandable  semantics  for  metadata 
o  At  the  core,  RDF  data  consists  of  nodes  and  attached  attribute/value 
pairs.  Nodes  can  be  any  web  resources  (pages,  servers,  basically 
anything  for  which  you  can  give  a  URI),  even  other  instances  of  metadata. 
Attributes  are  named  properties  of  the  nodes,  and  their  values  are  either 
atomic  (text  strings,  numbers,  etc.)  or  other  resources  or  metadata 
instances.  In  short,  this  mechanism  allows  us  to  build  labeled  directed 
graphs. 

•  DAML+OIL  extends  RDF  and  provides  a  means  to  define  ontologies  with  a 
formal  semantics 
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o  DAML+OIL  combines  the  machine  readability  of  XML,  the  standardization 
of  RDF,  and  the  expressive  power  of  an  ontological  language 

Early  in  the  project  we  developed  and  published  specifications  for  a  DAML+OIL 
ontology  which  we  used  to  capture  the  information  content  of  NOTAMs.  This  included 
representations  of  all  critical  capabilities  and  infra-structure  relevant  to  high-value 
NOTAMs 

•  Aviation  specific  environment  -  Aerodromes,  runways,  navaids,  lights,  routes,  fuel 

•  Underlying  knowledge  in  uniform  fashion  -  temporal,  spatial  (geographic) 
structures 

•  Aviation  requirements,  situations,  policies  -  landing  minima,  RNP,  MNP,  closures, 
failures, 

We  were  forced  to  develop  and/or  extend  DAML+OIL  representations  for  a  number  of 
areas  which  had  not  been  standardized  at  the  time  the  project  began. 

•  Temporal  ontology  extends  standard  DAML  Time  ontology 

•  We  developed  a  spatial/geographic  ontology  that  was  presented  as  a  draft  to  the 
DAML  Spatial  Ontology  Working  Group 

Several  technical  issues  were  addressed  and  resolved  in  this  work.  One  was  the  fact 
that  NOTAMs  often  contained  measurements  such  as  altitudes,  runway  lengths, 
distances,  relative  positions,  and  it  was  necessary  to  develop  a  general  representation 
of  measurements  that  allowed  for  variations  in  units  of  measurement  (e.g.  feet  vs. 
meters  vs.  miles)  and  measurement  origins  (altitude  above  sea  level  vs.  altitude  above 
ground  level). 

The  technique  used  to  deal  with  this  is  to  separate  out  the  notion  of  the  “description” 
of  a  quantity  or  measurement  from  the  quantity  of  measurement  itself.  As  an  example, 
consider  that  one  single  particular  length  might  be  expressed  in  two  different  ways  as 
“6000  feet”  or  “1  nautical  mile.”  We  developed  a  representation  that  separated  out  the 
description  used  in  the  text  from  the  underlying  object.  This  strategy,  originally  applied 
to  measurements,  turned  out  to  be  useful  for  other  things.  In  particular,  there  are 
several  ways  commonly  used  to  express  locations  in  NOTAMs  -  radial  fixes  from 
navaids,  GPS  coordinates,  waypoint  designators,  etc.  In  some  NOTAMs  multiple 
descriptions  were  given  of  the  same  point  on  the  ground  (commonly  navaid  fixes  and 
GPS  coordinates).  By  describing  all  of  these  as  instances  of  a  common  GeoPoint2D 
with  multiple  descriptions,  we  were  able  to  capture  the  content  of  the  NOTAM  in  a  way 
that  made  it  easy  to  perform  reasoning.  Another  problem  we  discovered  in  this  effort 
was  the  fact  that  many  of  the  geographic  regions  referred  to  in  NOTAMs  involved 
specification  of  sequences4  of  geographic  locations  (GeoPoint2Ds).  Representation  of 
sequences  is  an  area  where  the  DAML+OIL  representation  makes  no  commitment,  and 


4  The  variety  of  ways  that  such  sequences  are  represented  in  NOTAMs  is  quite  amazing.  Not  only  have  we 
discovered  over  60  different  patterns  for  specifying  a  single  position  consisting  of  a  latitude  and  longitude,  we  have 
discovered  hundreds  of  variations  in  the  way  that  these  specifications  are  combined  together  to  form  a  sequence,  and 
the  ways  that  they  are  combined  with  names  of  towns,  waypoints,  navaids,  etc.  Some  examples  of  this  are: 
“341028N690252E,  340710N685822E,  341012N685613E,  341359N685644E,  341432N6901 18E,  341359N690355E” 

“(PRiMOSTEN)  -  435848N  0155818E  (KISTANJE)  -  441030N  0153342E  (NOVIGRAD)  -  440630N  0152048E  " 

"501 137N0163347E-500839N016251 1E-500632N0162156E  -495215N0161848E-495039N0154230E-494607N0155058E-“ 

"FROM  STEFF  NCRP(N39  57  W75  15)  TO  SAVVY  NCRP  (N39  48  W75  27)  TO  DPONT  NCRP  (N39  41  W75  36)" 
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we  were  forced  to  make  use  of  the  sequential  nature  of  XML  lists.  We  have  proposed 
this  strategy  to  the  DAML+OIL  community.  As  the  project  progressed  we  extended  the 
ontology  and  this  extended  our  ability  to  represent  more  of  the  critical  NOTAM  content. 
We  also  made  an  effort  to  keep  up  with  the  rapidly  evolving  standards  for 
representation.  On  the  base  language  side  in  February  2004,  DAML+OIL  was 
succeeded  by  the  W3C  standard  Web  Ontology  Language  (OWL).  OWL  is  a  direct 
descendant  of  DAML+OIL,  and  we  were  able  to  revise  our  DAML+OIL  ontology  into  an 
OWL  ontology  with  relatively  little  effort.  At  the  same  time,  we  became  aware  of  the 
existing  EUROCONTROL  (European  Organisation  for  the  Safety  of  Air  Navigation) 
effort  on  developing  the  Aeronautical  Information  Exchange  Model  (AIXM),  a 
standardized  XML  representation  of  airspace  information,  designed  to  allow  sharing  of 
information  among  the  various  national  aviation  agencies  in  the  European  Union  (EU). 
We  were  informed  that  EUROCONTROL  was  in  the  process  of  designing  an  extension 
of  AIXM  to  represent  the  content  of  NOTAMs,  called  XNOTAM.  At  the  same  time  we 
found  that  the  FAA  and  NGA  in  the  US  had  come  to  an  agreement  with 
EUROCONTROL  to  support  the  developing  AIXM  and  XNOTAM  standards.  Through 
our  work  at  NGA  and  our  contacts  with  the  FAA,  we  were  invited  to  present  our  work  to 
the  EUROCONTROL  AIXM  Control  Board,  and  we  have  modified  our  representation  to 
make  it  more  compatible  with  the  directions  that  appeared  to  likely  for  XNOTAMs.  At 
this  point  XNOTAM  is  still  in  the  development  stage,  as  indicated  by  the 
EUROCONTROL  web  page  which  includes  the  following  paragraph: 

“XNOTAM”  in  2007.  The  main  objective  is  to  bring  the  temporality  to 
aeronautical  information  be  used  in  airborne  or  ground-based  systems,  to 
augment  and  in  time  replace  the  venerable  NOTAM.  The  XNOTAM  concept  will 
reflect  the  investments  already  made  in  information  systems  and  in  consequence 
will  be  fully  (backward)  compatible  with  the  current  NOTAM  system. 

With  the  close-out  of  the  initial  AFRL  ISO  NOTAMs  project,  harmonization  of  the 
OWL  NOTAM  representation  with  XNOTAM  will  be  carried  on  under  the  various  JMPS- 
related  follow-ons  to  this  project.  Currently,  BBN  is  engaged  in  transition  efforts  with 
AMC  through  integration  efforts  with  JMPS  via  the  Global  Planning  Common 
Component  (GPCC)  and  Tanker,  Airlift,  Special  Missions  (TASM)  delivery  order 
contracts  with  Hanscom  ESC.  In  both  cases,  BBN  is  participating  as  a  subcontractor  to 
TYBRIN  Corporation,  the  system  integrator.  GPCC  is  scheduled  to  field  in  April  2007, 
with  the  first  TASM  spiral  fielding  in  2008. 
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Results  and  Discussion 

Under  the  ISQ  NOTAMs  contract  BBN  has  developed  an  OWL  ontology  capable  of 
representing  a  substantial  portion  of  the  content  of  NOTAMs  and  supporting  retrieval 
and  reasoning  on  those  NOTAMs.  This  OWL  ontology  allows  us  to  represent  and 
reason  about  the  status  of  runways,  taxiways,  ground/air  communications,  navaids,  and 
other  aerodrome  capabilities.  This  includes  runway  closures,  snow  and  ice  conditions, 
and  quiet  hours  and  aerodrome-wide  usage  restrictions. 

While  it  is  important  to  be 
able  to  represent  such  status 
and  constraints  in  a  formal  and 
standardized  XML-based 
language  such  as  OWL,  this 
would  be  useless  if  we  were 
not  able  to  map  the  often 
cryptic,  highly  varied  text  of 
NOTAMs  produced  all  over  the 
world  into  this  standard 
representation.  Under  the  ISQ 
NOTAMs  project  we  have 
developed  natural  language 
parsing  and  understanding 
techniques  to  produce  a  new 

Figure  8:  Screenshot  of  graphically  represented  NOTAMs 
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generation  of  tools  that  can  efficiently  map  the  content  of  NOTAMs  into  the  ontology.  It 
is  abundantly  clear  that  NOTAMs  were  not  written  in  a  “dialect  of  English”,  but  rather 
formed  their  own  separate  sub-language  with  highly  specialized  vocabulary  and 
abbreviations,  local  syntax  quite  different  than  English,  and  a  high-level  structure  more 
like  a  linguistic  “pidgin”5.  Perhaps  more  important  is  that  there  are  a  large  number  of 
misspellings,  variant  abbreviations,  and  other  errors.  Presence  of  white  space  between 
words  is  often  optional,  and  the  choice  of  separating  punctuation  is  idiosyncratic.  This, 
plus  the  existence  of  a  wide  variety  of  low-frequency  “explanatory  text”  of  highly  variable 
structure  makes  it  inappropriate  to  attempt  complete  or  top-down  parsing  to  extract 
meaning.  The  most  effective  technique  for  parsing  in  this  case  is  a  cascade  of  finite 
state  transducers.  To  implement  this  process  we  have  developed  a  new,  highly  efficient, 
Java-based  finite  state  transducer  language,  called  FIST,  which  can  integrate  large 
vocabulary  phrasal  lexicons  (including  a  60,000  phrase  lexicon  derived  from  the  Digital 
Aeronautical  Flight  Information  File  (DAFIF)  waypoint  and  navaid  tables).  We  believe 
that  FIST  may  prove  useful  in  a  number  of  other  AF  message  parsing  problems  such  a 


5  A  simplified  language  derived  from  two  or  more  languages  is  called  a  pidgin.  It  is  a  contact  language  developed 
and  used  by  people  who  do  not  share  a  common  language  in  a  given  geographical  area.  . .  .the  structure  is  very 
simplistic.http://logos.uoregon.edu/explore/socioling/pidgin.html 
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METARs  (Meteorological  Aviation  Reports),  PIREPs  (Pilot  Reports),  etc.  FIST  is 
capable  of  parsing  over  15,000  NOTAMs  an  hour  on  a  standard  desktop  or  laptop  PC. 
As  shown  above,  these  tools  make  it  possible  to  break  down  the  often  large  set  of 
NOTAMs  for  a  given  aerodrome,  and  assign  them  to  different  resources  within  the 
aerodrome,  including  individual  runways,  taxiways,  lighting,  arresting  systems  and 
navaids. 

Parsing  and  representation  of  three-dimensional  geographical 
regions 

One  of  the  more  difficult  representational  and  parsing  problems  we  have  made 
substantial  progress  on  is  the  representation  of  complex  three  dimensional  airspace 
regions,  and  the  ability  to  map  NOTAM  text  into  OWL  annotations  sufficient  to  draw 
maps  of  affected  airspace.  These  include  both  polygonal  and  circular  regions,  as  well  as 
complex  corridors.  Some  examples  of  the  result  of  this  parsing  and  interpretation  are 
shown  below.  All  pictures  are  from  demonstrable  software  running  with  a  database  of 
over  250000  NOTAMs,  including  approximately  30,000  active  NOTAMs  obtained  from 
the  AMC  NOTAM  cache,  and  missions  obtained  from  the  Global  Decision  Support 
System  (GDSS). 


Figure  9:  Graphically  represented  NOTAMs  along  with  free-text  in  the  HISA  Map  View 


BBN  also  demonstrated  that  it  is  possible  to  use  “corporate  knowledge  sources”  such 
as  DAFIF  to  increase  the  vocabulary  of  the  ISO  NOTAMs  parsing  system,  and  also  to 
perform  certain  types  of  reasoning  about  the  objects  mentioned  in  the  NOTAMs  (e.g. 
mapping  implicit  references  to  geographic  locations  given  by  navaid  fixes  to  explicit 
latitude/longitude  points) 
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To  demonstrate  the  potential  of  the  OWL  annotation,  as  well  as  to  test  the  generality 
of  the  web-based  interface  to  ISQ 
NOTAMs,  we  integrated  the  ISQ  NOTAMs 
system  with  two  WCSS-based  situation 
awareness  and  decision  support  systems 
(HISA  and  GAMAT)  developed  under 
AFRL/HE  support,  which  are  currently 
being  evaluated  at  AMC 

These  integrations  demonstrate  an 
initial  set  of  reasoning  and  display 
capabilities  made  possible  by  semantic 
representation.  In  these  pictures  we  see 
the  screens  generated  by  a  user  who  has 
highlighted  a  particular  mission  from 

Kuwait  International  Airport  to  Frankfurt  Main,  and  then  requests  the  system  to  find 
the  NOTAMs  which  pertain  to  that  flight.  The  system  finds  the  NOTAMs  that  affect  the 

airports  involved  at  the  time  of  the  mission, 
and  (as  indicated  in  previous  pictures) 
shows  the  different  types  of  NOTAMs  at 
each  port.  In  addition,  the  system  performs 
three  dimensional  airspace  calculations  to 
determine  that  there  is  a  NOTAM 
describing  activities  in  a  region  crossed  by 
the  flight,  and  highlights  the  region  on  the 
map 


Figure  1 1:  Tree  view  of  NOTAMs  in  GAMAT 


We  have  demonstrated  that: 

Mapping  regions  facilitates  interpretation  by  pilots,  and  makes  it  easier  to 
detect  anomalies 
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Figure  12:  NOTAMs  displayed  in  GAM  AT 


uilding  a  model  of  the  airspace  facilities 


•  Which  aerodrome  equipment  and 
services  are  not  operating 
normally. 

•  Which  procedures  are  being 
modified  and  how. 


The  OWL-NOTAMS  System 
parses  NOTAM  text  and  produces 
machine-understandable 
annotations  capturing  critical  facts, 
including: 

•  Which  runways  are  affected  by 
NOTAMS,  and  which  runway 
conditions  are  being  reported. 


rocedures  and  capabilities 


Figure  13:  Port  NOTAMs  on  display  for  KBOS  (Boston  Logan  Airport) 

The  diagram  above  shows  some  displays  that  were  produced  as  part  of  the  ISQ 
NOTAMS/GAMAT  GWS  integration  experiment.  These  displays  formed  the  basis  for  the 
design  of  parts  of  the  NOTAMs  component  of  the  Joint  Mission  Planning  System 
(JMPS).  On  the  displays  above  we  make  use  of  the  fact  that  the  parser  can  determine 
which  runways  are  affected  by  NOTAMs,  and  combine  that  with  information  retrieved 
from  NGA’s  DAFIF  database  to  draw  “live  diagrams”  of  any  airfield,  where  runways 
affected  by  current  NOTAMs  are  highlighted,  and  in  which  the  user  can  click  on  a 
highlighted  runway  to  find  out  all  NOTAMs  that  mention  that  runway.  Additionally,  for 
each  airfield  that  has  issued  NOTAMs,  the  user  can  bring  up  a  tree-like  display  that 
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breaks  down  the  NOTAMs  by  category  (see  description  below).  A  single  NOTAM  may 
appear  more  than  once  in  this  list,  because  the  parser  may  assign  a  NOTAM  to  more 
than  one  category  -  for  example,  a  NOTAM  may  affect  a  runway,  it  may  mention  a  new 
vertical  obstruction  that  is  the  cause  of  the  issue,  and  may  specify  a  change  to 
procedures  for  using  that  runway.  For  any  runway  shown  in  the  display,  the  user  get  a 
color-coded  highlighted  version  of  the  NOTAM  indicating  the  key  phrases  found  by  the 
parser  that  led  it  to  categorize  the  NOTAM  -  the  runways,  the  lighting  systems,  the 
procedures,  etc.  The  user  may  also  see  the  entire  parse  of  the  NOTAM  in  a  tree 
structured  form,  though  this  is  primarily  of  use  for  the  ISO  NOTAMs  system  developers, 
and  would  not  be  expected  to  be  valuable  to  pilots  or  flight  managers. 

OWL  NOTAMs  representation  makes  it  possible  to  reason  about  the  impact  of 
airspace  NOTAMs  on  particular  planned  (executing)  flights.  The  OWL  NOTAMs 
representation  contains  complete  boundary  information  for  special  use  airspaces 
described  (announced  or  modified)  by  NOTAM,  including  Danger  Areas,  Warning 
Areas,  Live  Firing  Areas,  Glider  activity,  Parachute  Jumping  activity,  etc.  The  parser 
also  determines  the  vertical  bounds  of  the  airspace  described,  as  well  as  the  time 
periods  of  activity.  This  enables  a  reasoning  engine  to  determine  whether  a  given  flight 
plan  is  likely  to  fly  through  or  near  the  geographic  region  specified  by  the  NOTAM. 
Additionally,  it  allows  the  reasoner  to  determine  those  cases  where  the  NOTAM  is 
unlikely  to  affect  the  aircraft,  even  though  the  path  crosses  the  region,  because  the 
aircraft  will  be  sufficiently  above  (or  occasionally  below)  the  region,  or  will  be  crossing 
the  region  at  a  time  when  it  is  not  active. 


GAMAT  WCSS-GWM 


FHe  Navigate  Views  Display  Help 


What  three  dimensional  airspace  regions 
does  this  flight  pass  through? 


How  does  the  time  of  passage  relate  to 
the  active  times  for  these  regions? 


The  OWL-NOTAMS  System 
produces  spatial  and  temporal 
annotations  that  allow  systems 
to  plot  airspace  restrictions 
based  on  NOTAM  content  and 
answer  questions  such  as: 


Figure  14:  Spatial  and  temporal  annotations 
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Categorization  of  NOTAMs 


In  support  of  appropriate  dissemination  of  NOTAMs  we  have  developed  a  set  of  over 
one  hundred  categories  that  are  appropriate  for  distinguishing  the  potential  impact  of 
NOTAMs  on  a  mission.  These  can  be  roughly  characterized  in  terms  of  the  QCODEs 
that  would  be  used  to  represent  the  comparable  categories.  The  categories  are 
primarily  broken  down  by  the  type  of  object  being  described  (runway,  taxiway, 
navigational  aid,  vertical  obstruction,  aerodrome,  lighting  of  various  types,  etc.).  For 
many  of  these  categories  we  break  them  down  still  further  by  distinguishing  between 
descriptions  of  closure,  unavailability,  limitation  and  more  general  descriptions  of 
changes  in  the  condition  of  the  objects  involved.  The  set  of  QCODEs  that  we  have  used 
for  this  characterization  are  given  below  (where  we  use  the  suffix  LC  -  which  nominally 
means  “CLOSED”  for  the  more  general  notions  of  closure,  unavailability  and  limitation. 
This  list  does  not  include  all  possible  QCODEs,  but  it  does  include  all  QCODEs  which 
are  commonly  used  (occur  as  more  than  .5%  of  the  total  set  of  NOTAMs).  As  noted 
above,  if  these  QCODEs  were  consistently  and  accurately  applied  to  NOTAMs,  that 
would  go  a  long  way  to  improving  the  dissemination  of  NOTAMs.  Unfortunately,  almost 
50%  of  the  current  set  of  NOTAMs  either  do  not  have  meaningful  QCODEs,  or  have 
inaccurate  or  incomplete  QCODEs.  One  of  the  major  capabilities  of  the  ISQ  NOTAMs 
system  is  to  accurately  determine  the  QCODEs  for  a  much  larger  set  of  NOTAMs, 
currently  measured  to  be  about  80%.  The  QCODE-like  categories  we  use  are: 

QAA,  QAC,  QAF,  QAN,  QAP,  QAR,  QARLC,  QAT,  QAZ,  QCA,  QCALC,  QCELC,  QCG,  QCGLC, 
QCP,  QCPLC,  QCS,  QCSLC,  QCT,  QCTLC,  QFA,  QFALC,  QFALT,  QFC,  QFCLC,  QFF, 

QFFLC,  QFL, QFLLC,  QFM,  QFMLC,  QFTLC,  QFU,  QFULC,  QFW,  QFWLC,  QGJLC,  QI,  QKK, 
QL,  QLA,  QLB,  QLE, QLP,  QLX,  QLY,  QMALC ,  QMB,  QMH,  QMHLC,  QMN,  QMNLC ,  QMR, 
QMRLC,  QMRLC,  QMU,  QMWLC ,  QMX,  QMXLC,  QN,  QOA,  QOB,  QOE,  QOLLC,  QPA,  QPALC, 
QPD,  QPDLC,  QPH,  QPI,  QPILC,  QPM,  QPU,  QRA,  QRD,  QRM,  QRO,  QRP,  QRR,  QRT, 

QSA,  QSALC,  QSB,  QSC,  QSE,  QSF,  QSP,  QSSLC,  QST,  QSTLC,  QSV,  QSVLC,  QWA,  QWB, 
QWC,  QWD,  QWE,  QWF,  QWG,  QWL,  QWM,  QWP,  QWZ 

Much  more  information  is  available  from  the  parsed  NOTAMs  than  the  listing  of 
categories  above  implies.  Thus,  the  parsing  determines  the  exact  boundaries  of 
airspace  specified  in  a  NOTAM,  enabling  reasoning  systems  to  determine  whether  a 
given  NOTAM  is  likely  to  impact  a  given  flight  plan  or  its  alternates.  Additionally,  the 
parsing  makes  it  clear  which  runways  are  affected  by  closures  -  which  can  make  a  big 
difference  for  various  types  of  aircraft.  The  parsing  identifies  which  instrument 
procedures  are  being  modified,  which  exact  navigational  aids  are  being  referred  to,  and 
what  has  changed. 
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Conclusions  and  Transitions 

NGA  NOTAMs  Effort 


Current  NOTAM  Process 


Figure  15:  Augmenting  the  NGA  NOTAM  process  with  OWL-NOTAMs 

As  part  of  this  contract,  BBN  explored  the  applicability  of  the  ISQ  NOTAMs  technology 
to  problems  at  NGA.  We  designed,  prototyped,  and  in  conjunction  with  an  NGA 
nominated  partner  IMAPS,  delivered  an  initial  capability  to  use  the  ISQ  NOTAMs 
technology  to  update  the  NGA  corporate  worldwide  database  of  vertical  obstructions, 
based  on  incoming  NOTAMs. 

This  required  a  number  of  extensions  to  the  effort  done  under  the  base  effort.  As  part 
of  the  initial  proof  of  concept  effort  we  performed  work  in  the  following  areas: 

NOTAM  acquisition 

NGA  operates  in  a  classified  environment.  It  has  developed  a  special  mechanism 
to  obtain  NOTAMs  from  the  FAA  and  make  them  available  within  NGA.  The 
resulting  NOTAM  feed  is  not  accessible  as  a  web-based  system.  We  initially 
tested  the  development  of  the  NGA  capability  by  giving  them  access  to  the 
external  BBN  NOTAMs  server,  which  operated  as  a  parsing  server  and  obtained 
NOTAMs  from  the  AMC  NOTAM  cache.  This  system  was  replaced  by  a  system 
which  obtained  NOTAMs  by  the  direct  retrieval  from  NGA’s  Aeronautical 
Migration  System  (AMS),  a  Microsoft  Access  database  of  NOTAMs  obtained 
from  the  FAA.  In  the  process  we  discovered  that  there  were  minor  but  initially 
problematic  differences  between  the  structure  of  NOTAMs  seen  in  the  NGA  feed 
and  those  obtained  through  the  AMC  NOTAM  cache.  We  resolved  these  issues 
and  produced  a  system  that  allowed  the  BBN  parser  to  be  operated  entirely 
inside  NGA. 
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Vertical  Obstruction  Parsing  Improvements 

While  we  parsed  NOTAMs  that  contained  information  about  Vertical 
Obstructions,  the  detailed  information  in  these  NOTAMs  did  not  affect  the  types 
of  decisions  made  by  flight  managers,  and  thus  they  were  not  the  highest  priority 
for  AMC.  While  the  initial  parsing  coverage  was  good,  we  worked  to  improve 
extraction  of  specific  information  obstacle  type,  location  specification,  and  altitude 
specification. 


User  Interface  for  VO  NOTAM  evaluation 

In  order  to  incorporate  the  results  of  our  parsing  into  the  NGA  workflow  we 
designed  and  implemented  a  new  user  interface  to  show  NGA  analysts  the 
relation  between  the  raw  NOTAM  text  and  the  extracted  location  and  height.  This 
interface  was  patterned  after  the  existing  interface  used  to  input  information  into 
DVOF  (Digital  Vertical  Obstruction  File),  and  provided  the  necessary  ability  for 
skilled  human  review  of  the  results  of  the  parsing  and  semantic  representation 
process  before  the  resulting  information  was  input  to  DVOF. 


LIMM |MIL AN O  ACC  (COM  CENTRE)|M1520/04  NOTAMR 
M1490/04  Q)  LIMM/QOLAS/IV/M/AE/000/999/4422N00837E010  A) 
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SITE  /VARAZZE-PIANI  D'INVREA/  PSN  442231N  083716E  HGT 
15M/49FT  AGL  90M/295FT  AMSL  OBST  LGT  OUT  OF  SER 


|  1)  Input 


Figure  16:  Process  for  handling  DVOF  NOTAMs  at  NGA  with  OWL-NOTAMs 
Interface  to  DVOF  input  mechanism 

With  NGA’s  help  we  designed  and  implemented  a  mechanism  to  input  into  DVOF  the 
parsing  results,  as  verified  by  an  analyst. 

In  support  of  an  operational  prototype  system,  BBN  worked  with  NGA  and  IMAPS  to 
separate  the  ISO  NOTAMs  code  into  two  components,  the  parsing  engine  (“server”)  and 
display  and  DVOF  (Digital  Vertical  Obstruction  File)  formatter  (“client”)  components. 

BBN  worked  with  IMAPS  to  allow  them  to  produce  a  version  of  the  client  software  which 
they  could  readily  maintain  at  NGA. 
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Recommendations 


Relationship  to  an  alternative  approach  to  providing  these  capabilities 

We  started  this  effort  with  the  following  goal:  make  NOTAMs  understandable  by 
machine.  We  have  demonstrated  that  if  programs  can  reason  about  the  content  of 
NOTAMs,  then  we  can  provide:  intelligent  dissemination,  mapping,  alerting  and 
airspace  database  update 

Over  the  course  of  this  effort  it  became  clear  that  there  were  two  basic  approaches  to 
providing  this  capability: 

1)  Provide  tools  for  precisely  formatted  NOTAM  input  (e.g.  XML  standard  such  as 
AIXM)  and  encourage  (enforce)  their  use 

2)  Take  existing  NOTAM  stream  and  produce  annotations  on  the  NOTAMs  that 
represent  their  content  in  machine  understandable  form  (e.g.  AIXM) 

Approach  1  is  available  only  to  official  agencies  like  the  FAA  or  EUROCONTROL, 
who  have  official  control  over  the  activities  of  NOTAMs  issuers.  Approach  2  is  the  one 
we  have  taken.  Clearly,  if  approach  1  is  applied  in  a  uniform  worldwide  manner,  then 
approach  2  would  no  longer  be  necessary.  Much  progress  is  being  made  on  approach 
1,  with  the  promulgation  of  the  AIXM  standard  by  EUROCONTROL,  the  decision  by  the 
FAA  and  NGA  to  support  this  standard,  and  the  later  decision  by  ICAO  to  accept  this 
approach.  Unfortunately,  this  is  a  very  long  term  project.  Even  in  Europe,  which  made 
the  decision  to  move  towards  AIXM,  a  standard  for  NOTAMs  has  still  not  been 
approved.  Building  of  systems  to  help  people  issue  NOTAMs  according  to  that  standard 
will  then  require  substantial  funding  and  development.  It  is  not  expected  that  this  will 
take  place  for  at  least  another  ten  years.  Making  such  technology  available  and 
enforcing  its  use  around  the  world  will  pose  many  other  technical,  financial  and 
particularly  political  hurdles.  Finally,  as  is  clear  from  the  use  of  automated  NOTAMs 
entry  tools  within  the  US  DoD,  any  such  tool  must  contain  ways  to  break  out  of  the 
standardized  format  to  report  truly  unusual  situations  -  and  this  leaves  open  the 
possibility  (likelihood)  that  many  NOTAMs  will  be  issued  in  a  non-standard  form.  Thus,  it 
is  our  firm  belief  that  for  the  foreseeable  future  it  will  be  necessary  to  combine  the 
two  approaches. 
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Appendix  A  -  Transition  Opportunities 

1  Transition  Opportunities 
1.1  Introduction 

During  the  course  of  the  research  first  initiated  in  2003,  BBN  worked  with  Mr. 
DePalma  and  representatives  of  AMC,  Hanscom  AFB,  AFRL,  Jeppesen, 
EUROCONTROL,  and  the  FAA  to  determine  appropriate  transition  opportunities  for  the 
NOTAMs  capabilities.  Below,  we  list  the  transitions  that  BBN  has  worked  on,  as  well  as 
future  opportunities  that  are  currently  in  progress. 

1.2NGA  DVOF 

In  2003,  BBN  began  discussions  with  part  of  the  National  Imagery  and  Mapping 
Agency  (later  known  as  the  National  Geospatial-Intelligence  Agency)  to  use  the  parsing 
and  reasoning  capabilities  of  BBN’s  NOTAMs  work  within  their  organization.  Working 
with  Chuck  McGaugh  and  Barry  Herbert,  BBN  was  able  to  define  an  integration  path 
that  allowed  BBN  to  set  up  a  NOTAMs  server  that  would  parse  and  identify  NOTAMs 
that  corresponded  to  vertical  obstructions  -  man-made  obstructions  such  as  towers, 
buildings,  radio  masts,  and  power  lines,  which  need  to  be  monitored  and  managed 
through  the  Digital  Vertical  Obstruction  File.  BBN  developed  a  GUI  that  would  allow 
NGA  analysts  to  review  these  vertical  obstruction  NOTAMs  with  key  fields  parsed  and 
highlighted,  modify  them  as  necessary,  and  output  them  for  inclusion  in  the  formal 
DVOF  database. 

NGA  identified  IMAPS,  LLC  of  St.  Louis  (now  a  part  of  SAIC)  as  the  integration 
contractor,  who  would  be  responsible  for  transitioning  the  initial  capability,  installing  the 
NOTAMs  server  and  rewriting  the  GUI  for  use  at  NGA.  BBN  has  worked  closely  with 
IMAPS  with  this  transition,  and  initial  transition  was  scheduled  for  the  end  of  March 
2006. 

1.3  JMPS/NOTAMs  Integration 

Through  discussions  with  AFRL,  Hanscom  ESC,  and  AMC,  BBN  received  an 
additional  $500k  of  funding  in  early  2005  to  transition  the  NOTAMs  capability  into  AMC 
through  integration  with  the  JMPS  mission  planning  tools.  BBN  worked  closely  with 
TYBRIN  Corporation,  BAE  Systems,  and  Computer  Sciences  Corporation  to  develop 
the  initial  capabilities,  where  BBN  would  provide  a  web  services  interface  for  JMPS  to 
query.  JMPS  would  provide  BBN’s  web  service  with  a  Common  Route  Definition  file 
that  contained  a  route  of  interest  to  mission  planners,  and  BBN’s  parsing  and  reasoning 
capabilities  would  determine  which  NOTAMs  would  be  of  interest  based  on  route 
segments  and  identification  of  waypoints,  airfields,  and  navaids  using  geospatial 
reasoning  capabilities.  NOTAMs  of  interest  are  returned  to  JMPS,  which  are  then 
graphically  displayed  on  a  map,  and  made  available  to  mission  planners  through  a  tree 
view  capability. 
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1.4GPCC 

These  integration  efforts  continued  through  the  Global  Planning  Common 
Component  program,  also  with  TYBRIN  Corporation,  where  the  NOTAMs  server  and 
web  services  were  defined  as  common  components  in  the  new  architecture.  Under  this 
program,  the  integration  between  BBN’s  NOTAMs  capabilities  and  JMPS  was  tightened, 
the  parser  accuracy  was  heightened  through  constant  interaction  between  TYBRIN  and 
BBN,  and  the  GPCC-identified  testing  squadron  was  able  to  provide  additional  areas  for 
improvement,  both  within  the  GUI  itself,  and  with  presentation  of  NOTAMs  and 
additional  parsing  issues  to  improve  accuracy.  This  program  will  result  in  a  NOTAMs 
parser  installed  at  AMC  within  the  Tanker  Airlift  Control  Center  (TACC)  enclave. 

This  work  continues  through  2006,  with  the  focus  on  the  effort  being  through  the 
categorization  of  NOTAMs,  allowing  flight  planners  to  define  their  own  categories  to 
organize  NOTAMs  into  different  levels  of  severity.  BBN  is  also  working  closely  with 
TYBRIN  and  the  FAA  to  install  and  maintain  a  parser  within  the  FAA,  alongside  DINS  - 
the  GPCC  effort  will  ultimately  transition  from  using  a  parser  co-located  in  the  TACC  to 
the  parser  hosted  at  the  FAA,  which  can  then  be  accessed  from  any  number  of 
authorized  locations  without  the  need  for  multiple  parser  instances.  In  addition,  BBN  is 
developing  capabilities  to  parse  and  reason  over  additional  data  sources,  such  as 
graphical  Temporary  Flight  Restrictions  (TFRs),  Special  Use  Airspaces  (SUAs),  and 
data  from  the  Enhanced  Traffic  Management  System  (ETMS),  which  will  be  made 
available  to  JMPS. 

This  capability  is  scheduled  for  summer  2006,  with  delivery  to  AMC  scheduled  in  late 
2006. 
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Appendix  B  -  Future  Research/Transition  Opportunities: 
TASM 

In  addition  to  the  GPCC  effort,  BBN  is  collaborating  with  TYBRIN  Corporation, 
Northrop  Grumman,  and  the  Georgia  Tech  Research  Institute  on  the  TASM  program, 
part  of  the  MPEC  delivery  order  out  of  Hanscom  AFB.  In  this  program,  BBN’s  NOTAMs 
capabilities  will  continue  to  be  made  available  as  a  common  component  through  GPCC, 
and  BBN  will  be  involved  integration  efforts  through  the  2009  timeframe  and  beyond. 
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Appendix  C  -  Lists  of  Symbols,  Abbreviations,  and  Acronyms 


AFMC 

AFRL 

AIXM 

AMC 

AMS 

ARTCC 

ATD 

COTR 

DAFIF 

DAML 

DINS 


Air  Force  Materiel  Command 

Air  Force  Research  Lab 

Aeronautical  Information  Exchange  Model 

Air  Mobility  Command 

Aeronautical  Migration  System 

Air  Route  Traffic  Control  Center 

Advanced  Technology  Demonstration 

Contracting  Officer’s  Technical  Representative 

Digital  Aeronautical  Flight  Information  File 

DARPA  Agent  Markup  Language 

Defense  Internet  NOT AM  Service 


DoD 

DVOF 

ESC 

EUROCONTROL 

FAA 

FIR 

FIST 

FM 

GAMAT 

GDSS 

GPCC 

GUI 

ICAO 

IdiON 

IFM 

IMT 

IR&D 

JMPS 

KFDC 

MAF-CAF 

METAR 

NAIMES 

NAS 

NGA 

NIMA 

NOTAM 

OIL 

OWL 

PI 

PIREP 

RDF 

SES 

TACC 

UIR 

VTACC 

W3C 

WCSS 

XML 


Department  of  Defense 
Digital  Vertical  Obstruction  File 
Electronic  Systems  Command 

European  Organisation  for  the  Safety  of  Air  Navigation 

Federal  Aviation  Agency 

Flight  Information  Region 

Finite  State  Transducer 

Flight  Manager 

Global  Air  Mobility  Advanced  Technology 
Group  Decision  Support  System 
Global  Planning  Common  Component 
Graphical  User  Interface 
International  Civil  Aviation  Organization 
Intelligent  Distribution  of  NOT AMs 
Integrated  Flight  Management 
Integrated  Management  Tool 
Internal  Research  and  Development 
Joint  Mission  Planning  System 
ICAO  code  for  Washington,  DC 
Mobility  Air  Forces  -  Combat  Air  Forces 
Meteorological  Aviation  Report 

NAS  Aeronautical  Information  Management  Enterprise  System 

National  Airspace  System 

National  Geospatial-Intelligence  Agency 

National  Imagery  and  Mapping  Agency 

Notice  to  Airman 

Ontology  Integration  Language 

Web  Ontology  Language 

Principal  Investigator 

Pilot  Report 

Resource  Description  Framework 
Senior  Executive  Service 
Tanker  Airlift  Control  Center 
Upper  Flight  Information  Report 
Virtual  Tanker  Airlift  Control  Center 
World  Wide  Web  Consortium 
Work  Centered  Support  Systems 
Extensible  Markup  Language 
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Appendix  D  -  QCODE  definitions: 


QCODE  2nd  &  3rd  LETTERS 

(A)  Airspace  Organization 
(C)  Communications  and  Radar 

(F)  Facilities  and  Services 

(G)  Military 

(I)  Instrument  and  Microwave  Landing 

(L)  Lighting 

(M)  Movement  and  Landing  Area 

(N)  Terminal  and  En-route  Navigation 

(O)  Other  Information 

(P)  Air  Traffic  Procedures 

(R)  Airspace  Restrictions 

(S)  Air  Traffic  and  VOLMET  Services 

(T)  Hazard 

(W)  Warnings 

(X)  Other 

Airspace  Organization  (A) 


AA 

MINIMUM  ALTITUDE 

AC 

CONTROL  ZONE 

AD 

ADIZ 

AE 

CONTROL  AREA 

AF 

FLIGHT  INFORMATION  REGION  (FIR) 

AG 

GENERAL  FACILITY 

AH 

UPPER  CONTROL  AREA 

AL 

MINIMUM  USABLE  FLIGHT  LEVEL 

AN 

AIR  NAVIGATION  ROUTE 

AO 

OCEANIC  CONTROL  ZONE  (OCA) 

AP 

REPORTING  POINT 

AR 

ATS  ROUTE 

AT 

TERMINAL  CONTROL  AREA  (TMA) 

AU 

UPPER  FLIGHT  INFORMATION  REGION 

AV 

UPPER  ADVISORY  AREA 

AX 

INTERSECTION 

AZ 

AERODROME  TRAFFIC  ZONE  (ATZ) 

Top 

Communications  and  Radar  (C) 

CA  AIR/GROUND  FACILITY 

CE  ENROUTE  SURVELLENCE  RADAR 

CG  GROUND  CONTROLLED  APPROACH  SYSTEM  (GCA) 

CL  SELECTIVE  CALLING  SYSTEM 

CM  SURFACE  MOVEMENT  RADAR 

CP  PAR 

CR  SURVEILLANCE  RADAR  ELEMENT  OF  PAR  SYSTEM 

CS  SECONDARY  SURVEILLANCE  RADAR 


39 


CT 

Top 


TERMINAL  AREA  SURVEILLANCE  RADAR 


Facilities  and  Services  (F) 


FA 

FB 

FC 

FD 

FF 

FG 

FH 

FL 

FM 

FO 

FP 

FS 

FT 

FU 

FW 

FZ 

Top 


AERODROME 

BRAKING  ACTION  MEASUREMENT  EQUIPMENT 

CEILING  MEASUREMENT  EQUIPMENT 

DOCKING  SYSTEM 

FIRE  FIGHTING  AND  RESCUE 

GROUND  MOVEMENT  CONTROL 

HELICOPTER  ALIGHTING  AREA/PLATFORM 

LANDING  DIRECTION  INDICATOR 

METEOROLOGICAL  SERVICE 

FOG  DISPERSAL  SYSTEM 

HELIPORT 

SNOW  REMOVAL  EQUIPMENT 

TRANSMISSOMETER 

FUEL  AVAILABILITY 

WIND  DIRECTION  INDICATOR 

CUSTOMS 


Military  (G) 


GA 

GB 

GC 

GD 

GE 

GF 

GG 

GH 

Gl 

GJ 

GK 

GL 

GM 

GO 

GP 

GR 

GS 

GT 

GU 

GZ 

Top 


PULSATING/STEADY  VISUAL  APPROACH  SLOPE  INDICATOR 

OPTICAL  LANDING  SYSTEM 

TRANSIENT  MAINTENANCE 

STARTER  UNIT 

SOAP 

DEMINERALIZED  WATER 

OXYGEN 

OIL 

DRAG  CHUTES 
ASR 

PRECISION  APPROACH  LANDING  SYSTEM 

FACSFAC 

LOCALIZER 

WARNING  AREA 

MILITARY  OPERATIONS  AREA  (MOA) 

DIVERSE  DEPARTURE 
NITROGEN 

IFR  TAKE-OFF  MINIMUMS  AND  DEPARTURE  PROCEDURES 
DE-ICE 

BASE  OPERATIONS 


Instrument  and  Microwave  Landing  (I) 


1C  ILS 

ID  DME  ASSOCIATED  WITH  ILS 

IG  GLIDE  PATH  (ILS) 

II  INNER  MARKER  (ILS) 
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IL  LOCALIZER  (ILS) 

IM  MIDDLE  MARKER  (ILS) 

10  OUTER  MARKER  (ILS) 

IS  ILS  CATEGORY  I 

IT  ILS  CATEGORY  II 

IU  ILS  CATEGORY  III 

IW  MLS 

IX  LOCATOR,  OUTER,  (ILS) 

IY  LOCATOR,  MIDDLE  (ILS) 

Top 

Lighting  (L) 


LA 

LB 

LC 

LD 

LE 

LF 

LH 

LI 

LJ 

LK 

LL 

LM 

LP 

LR 

LS 

LT 

LV 

LW 

LX 

LY 

LZ 

Top 


APPROACH  LIGHTING  SYSTEM 
AERODROME  BEACON 
RUNWAY  CENTERLINE  LIGHTS 
LANDING  DIRECTION  INDICATOR  LIGHTS 
RUNWAY  EDGE  LIGHTS 
SEQUENCED  FLASHING  LIGHTS 
HIGH  INTENSITY  RUNWAY  LIGHTS 
RUNWAY  END  IDENTIFIER  LIGHTS 
RUNWAY  ALIGNMENT  INDICATOR  LIGHTS 

CATEGORY  II  COMPONENTS  OF  APPROACH  LIGHTING  SYSTEM 
LOW  INTENSITY  RUNWAY  LIGHTS 

MEDIUM  INTENSITY  RUNWAY  LIGHTS 

PRECISION  APPROACH  PATH  INDICATOR 

ALL  LANDING  AREA  LIGHTING  FACILITIES 

STOPWAY  LIGHTS 

THRESHOLD  LIGHTS 

VISUAL  APRROACH  SLOPE  INDICATOR 

HELIPORT  LIGHTING 

TAXIWAY  CENTER  LINE  LIGHTS 

TAXIWAY  EDGE  LIGHTS 

RUNWAY  TOUCH  DOWN  ZONE  LIGHTS 


Movement  and  Landing  Area  (M) 


MA 

MOVEMENT  AREA 

MB 

BEARING  STRENGTH 

MC 

CLEARWAY 

MD 

DECLARED  DISTANCES 

MG 

TAXIING  GUIDANCE  SYSTEM 

MH 

RUNWAY  ARRESTING  GEAR 

MK 

PARKING  AREA 

MM 

DAYLIGHT  MARKINGS 

MN 

APRON 

MP 

AIRCRAFT  STANDS 

MR 

RUNWAY 

MS 

STOPWAY 

MT 

THRESHOLD 

MU 

RUNWAY  TURNING  BAY 

MW 

STRIP 
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MX 

Top 


TAXIWAY 


Terminal  and  En-route  Navigation  (N) 


NA 

NB 

NC 

ND 

NF 

NL 

NM 

NN 

NT 

NV 

NX 

Top 


ALL  RADIO  NAVIGATION  FACILITIES 

NDB 

DECCA 

DME 

FAN  MARKER 

LOCATOR 

VOR/DME 

TACAN 

VORTAC 

VOR 

DIRECTION  FINDING  STATION 


Other  Information  (O) 

OA  AERONAUTICAL  INFORMATION  SERVICE 

OB  OBSTACLE 

OE  AIRCRAFT  ENTRY  REQUIREMENTS 

OL  OBSTACLE  LIGHTS 

OR  RESCUE  COORDINATION  CENTER 

Top 


Air  Traffic  Procedures  (P) 


PA 

PD 

PF 

PH 

PI 

PL 

PM 

PO 

PP 

PR 

PT 

PU 

PX 

PZ 

Top 


STANDARD  INSTRUMENT  ARRIVAL  (STAR) 
STANDARD  INSTRUMENT  DEPARTURE  (SID) 
FLOW  CONTROL  PROCEDURES 
HOLDING  PROCEDURES 
INSTRUMENT  APPROACH  PROCEDURE 
OBSTACLE  CLEARANCE  LIMIT 
AERODROME  OPERATING  MINIMA 
OBSTACLE  CLEARANCE  ALTITUDE 
OBSTACLE  CLEARANCE  HEIGHT 
RADIO  FAILURE  PROCEDURE 
TRANSITION  ALTITUDE 
MISSED  APPROACH  PROCEDURE 
MINIMUM  HOLDING  ALTITUDE 
ADIZ  PROCEDURE 


Airspace  Restrictions  (R) 


RA  AIRSPACE  RESERVATION 

RD  DANGER  AREA 

RO  OVERFLYING  OF 

RP  PROHIBITED  AREA 

RR  RESTRICTED  AREA 

RT  TEMPORARY  RESTRICTED  AREA 
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Top 

Air  Traffic  and  VOLMET  Services  (S) 


SA 

SB 

SC 

SE 

SF 

SL 

SO 

SP 

SS 

ST 

SU 

SV 

SY 

Top 


AUTOMATIC  TERMINAL  INFORMATION  SERVICE  (ATIS) 

ATS  REPORT  OFFICE 

AREA  CONTROL  CENTER 

FLIGHT  INFORMATION  SERVICE 

AERODROME  FLIGHT  INFORMATION  SERVICE  (AFIS) 

FLOW  CONTROL  CENTER 

OCEANIC  AREA  CONTROL  CENTER 

APPROACH  CONTROL 

FLIGHT  SERVICE  STATION 

AERODROME  CONTROL  TOWER 

UPPER  AREA  CONTROL  CENTER 

VOLMENT  BROADCAST 

UPPER  ADVISORY  SERVICE 


Hazard  (T) 


TT  MIJI 

Top 


Warnings  (W) 


WA 

WB 

WC 

WD 

WE 

WF 

WG 

WJ 

WL 

WM 

WP 

WS 

WT 

WV 

WZ 

Top 


AIR  DISPLAY 
AEROBATICS 

CAPTIVE  BALLOON  OR  KITE 
DEMOLITION  OF  EXPLOSIVES 
EXERCISES 
AIR  REFUELING 
GLIDER  FLYING 
BANNER/TARGET  TOWING 
ASCENT  OF  FREE  BALLOON 
MISSLE,  GUN  OR  ROCKET  FIRING 
PARACHUTE  JUMPING  EXERCISE 
BURNING  OR  BLOWING  GAS 
MASS  MOVEMENT  OF  AC  FT 
FORMATION  FLT 
MODEL  FLYING 


Other  (X) 

XX  PLAIN  LANGUAGE 


43 


QCODE  4th  &  5th  LETTERS 

(A)  Availability 
(C)  Change 

(G)  Military 

(H)  Hazard  Conditions 
(L)  Limitations 

(X)  Other 

Availability  (A) 


AC 

AD 

AF 

AG 

AH 

AK 

AM 

AN 

AO 

AP 

AR 

AS 

AU 

AW 

AX 

Top 


WITHDRAWN  FOR  MAINTENANCE 
AVAILABLE  FOR  DAYLIGHT  OPERATIONS 
FLIGHT  CHECKED  AND  FOUND  RELIABLE 

OPERATING  BUT  GROUND  CHECKED  ONLY,  AWAITING  FLIGHT  CHECK 

HOURS  OF  SERVICE  ARE 

RESUMED  NORMAL  OPERATIONS 

MILITARY  OPERATIONS  ONLY 

AVAILABLE  FOR  NIGHT  OPERATIONS 

OPERATIONAL 

PRIOR  PERMISSION  REQUIRED 
AVAILABLE,  PRIOR  PERMISSION  REQUIRED 
UNSERVICEABLE 
NOT  AVAILABLE 
COMPLETELY  WITHDRAWN 

PREVIOUSLY  PROMULGATED  SHUTDOWN  HAS  BEEN  CANCELLED 


Change  (C) 


CA 

ACTIVATED 

CC 

COMPLETED 

CD 

DEACTIVATED 

CE 

ERECTED 

CF 

FREQUENCY  CHANGED  TO 

CG 

DOWNGRADED  TO 

CH 

CHANGED 

Cl 

IDENTIFICATION  OR  RADIO  CALL  SIGN  CH/ 

CL 

REALIGNED 

CM 

DISPLACED 

CO 

OPERATING 

CP 

OPERATING  ON  REDUCED  POWER 

CR 

TEMPORARILY  REPLACED  BY 

CS 

INSTALLED 

CT 

Top 

ON  TEST,  DO  NOT  USE 

Military  (G) 

GA 

NOT  COINCIDENTAL  WITH  ILS/PAR 

GB 

IN  RAISED  POSITION 

GC 

TAIL  HOOK  ONLY 

GD 

OFFICIAL  BUSINESS  ONLY 
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GE  EXPECT  LANDING  DELAY 

GF  EXTENSIVE  SERVICE  DELAY 

GG  UNUSABLE  BEYOND 

GH  UNUSABLE 

Gl  UNMONITORED 

GV  NOT  AUTHORIZED 

Top 


Hazard  Conditions  (H) 


HA 

HB 

HC 

HD 

HE 

HF 

HG 

HH 

HI 

HJ 

HK 

HL 

HM 

HN 

HO 

HP 

HQ 

HR 

HS 

HT 

HU 

HV 

HW 

HX 

HY 

HZ 

Top 


BRAKING  ACTION  IS 
BRAKING  COEFFICIENT  IS 

COVERED  BY  COMPACTED  SNOW  TO  A  DEPTH  OF 
COVERED  BY  DRY  SNOW  TO  A  DEPTH  OF 
COVERED  BY  WATER  TO  A  DEPTH  OF 
TOTALLY  FREE  OF  SNOW  AND  ICE 
GRASS  CUTTING  IN  PROGRESS 
HAZARD  DUE  TO 
COVERED  BY  ICE 

LAUNCH  PLANNED 
MIGRATION  IN  PROGRESS 
SNOW  CLEARANCE  COMPLETED 
MARKED  BY 

COVERED  BY  WET  SNOW  OR  SLUSH  TO  A  DEPTH  OF 

OBSCURED  BY  SNOW 

SNOW  CLEARANCE  IN  PROGRESS 

OPERATIONS  CANCELLED 

STANDING  WATER 

SANDING 

APPROACH  ACCORDING  TO  SIGNAL  AREA  ONLY 

LAUNCH  IN  PROGRESS 

WORK  COMPLETED 

WORK  IN  PROGRESS 

CONCENTRATION  OF  BIRDS 

SNOW  BANKS  EXIST 

COVERED  BY  FROZEN  RUTS  AND  RIDGES 


Limitations  (L) 


LA 

LB 

LC 

LD 

LE 

LF 

LG 

LH 

LI 

LK 

LL 

LN 

LP 


OPERATING  ON  AUXILIARY  POWER  SUPPLY 
RESERVED  FOR  AIRCRAFT  BASED  THEREIN 
CLOSED 
UNSAFE 

OPERATING  WITHOUT  AUXILIARY  POWER  SUPPLY 
INTERFERENCE  FROM 
OPERATING  WITHOUT  IDENTIFICATION 
UNSERVICEABLE  FOR  AIRCRAFT  HEAVIER  THAN 
CLOSED  TO  IFR  OPERATIONS 

OPERATING  AS  A  FIXED  LIGHT 
USABLE  FOR  LENGTH  OF  AND  WIDTH  OF 

CLOSED  TO  ALL  NIGHT  OPERATIONS 
PROHIBITED  TO 
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LR  AIRCRAFT  RESTRICTED  TO  RUNWAYS  AND  TAXIWAYS 

LS  SUBJECT  TO  INTERRUPTION 

LT  LIMITED  TO 

LV  CLOSED  TO  VFR  OPERATIONS 

LW  WILL  TAKE  PLACE 

LX  OPERATING  BUT  CAUTION  ADVISED  DUE  TO 

LY  EFFECTIVE 

TT  HAZARD 

Top 

Other  (X) 

XX  PLAIN  LANGUAGE 
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Alphabetical  list  of  OWL  Concepts  used  by  the  ISQ  NOTAMs  System 


ATSReportingOf f ice 
ATSRoute 

ATSRouteActivation 

ATSRouteClosed 

ATSRouteStatusReport 

ATZStatus 

ATZStatusReport 

AUS Identifier 

Activated 

Active 

AerialDi splay 

AerialDi splayS t a tusReport 

AerialObstacle 

AerialObstacleSt a tusReport 

Aerobatics 

AerobaticsStatusReport 

AerodromeBeacon 

AerodromeBeaconStatus 

AerodromeClosed 

AerodromeClosedReport 

AerodromeCommunicationFacility 

AerodromeCommunicationFacilityFrequ 

encySpec 

AerodromeCommunicationFacilityOutOf 

Service 

AerodromeCommunicationFacilityStatu 

sReport 

AerodromeControlTower 
AerodromeControlTower Frequency Spec 
AerodromeControlTowerOutOf Service 
AerodromeControlTowerStatusReport 
AerodromeFlightlnf ormationService 
Aer odr omeFl ight In format ionServiceFr 
equencySpec 

AerodromeFlightlnf ormationServiceOu 
tOf Service 

AerodromeFlightlnf ormationService St 
atusReport 

Ae r odr omeHoursOf Service 

AerodromeLimitedReport 

AerodromeRef erence Point 

AerodromeServiceStatus 

Aer odr omeSt a tusReport 

AipPublication 

AipSection 

AirRef ueling 

AirSpeedRestriction 

AirTraf f icProcedureStatus 

Aircraftcrossing 

Aircraf tMDS 

Air craft Stand 

Airfield 


Airport 

AirspaceEntryPermission 

AirspaceOrganization 

AirspaceOrganizationStatus 

AirspaceReservation 

AirspaceReservationActivationReport 

AirspaceReservationHead 

AirspaceReservationPhrase 

AirspaceReservationStatus 

AlongBoundary 

AltitudeMinimum 

AltitudeReservation 

AltitudeReservationSt a tusReport 

Antenna 

AntennaS tructureRegist rat ion 

ApproachControlService 

ApproachControlServiceFr equencySpec 

ApproachControlServiceOutOf Service 

ApproachControlService St atusReport 

ApproachControl Services 

ApproachMinimums 

ApproachType 

ApprovalRequired 

Apron 

ApronClosed 

ApronStatus 

AreaControlCenter 

AreaControlCenterFrequencySpec 

AreaControlCenterOutOf Service 

AreaControlCenter St atusReport 

ArrestingGear 

ArrestingGearStatus 

ArrestingGear St atusReport 

ArrestingGear Type 

ArrestingGearUnavailableReport 

As centOf FreeBal loons 

As centOf FreeBal loons St atusReport 

AutomaticTerminal Inf ormationService 

AutomaticTerminal Inf ormationService 

Frequency Spec 

AutomaticTerminal Inf ormationService 
OutOf Service 

AutomaticTerminal Inf ormationService 

StatusReport 

Available 

Bearing 

BearingStrength 

Belfry 

BirdWatchCondition 

Bridge 

Building 

CTRAirspace 
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Cable 

CaptiveBalloonOrKite 

CaptiveBalloonOrKiteStatusReport 

CardinalDirection 

Category 

CategoryMinimumAltitude 

CategoryVisibilityMinimum 

Caused 

CautionWarning 

Chimney 

ClassA_Air space 

ClassBAirspace 

ClassBAir spaces t a tusReport 

ClassBAirspaceUnavailableStatusRepo 

rt 

ClassB_Airspace 
ClassC_Air space 
Class D_Air space 
ClassE_Airspace 
Class F_Air space 
ClassG_Air space 
Climb Inst ructions 
ClockTime 
Closed 

CommsHoursOf Service 

CommsOutOf Service 

CommunicationFrequencySpec 

CommunicationFrequencyStatus 

Corridor 

Country 

Crane 

DFEquipment 

DMEArcProcedure 

DMEDistance 

DMEEquipment 

DMESt a tusReport 

DMEUnavailableReport 

DangerAirspaceHead 

DangerArea 

DangerAreaActivated 

Danger AreaActivationReport 

Danger Ar eaSt a tus 

Date 

Day 

DayNight 

DayOfWeek 

Delay 

De limit edName 
DemolitionOf Explosives 
Dimen sionDe script ion 
Drilling 
DropZone 

EnrouteNavigationFacility 

EnrouteSurveillanceRadar 


EnrouteSurveillanceRadarFacilitySta 

tusReport 

EnrouteSurveillanceRadarFacilityUna 

vail able St a tusReport 

Exercise 

ExerciseSt a tusReport 

FDCAnnouncement 

Facility 

Fire Fight ingCapabilitySta tusReport 

FireFightingCapabilityUnavailableRe 

port 

FlightLevel 

FlightRestriction 

Fraction 

FrequencyDe script ion 

FuelAvailabilityStatus 

FuelCapability 

FuelCapabilitySta tusReport 

GCARadarFacility 

GCARadarFacilitySta tusReport 

GCARadarFacilityUnavailableStatusRe 

port 

GeoAltitude 

GeoAltitudeDe script ion 

GeoAltitudeRange 

GeoBox 

GeoPoint2D 

GeoRegion 

GeoVector 

GlidePathStatus 

GlidePathSt a tusReport 

GlidePathUnavailableReport 

Glider 

GliderLandingSite 

Glider StatusReport 

GlobalPositioningSystem 

GridPosition 

GroundObst ruction 

Gr oundObs t rue tionDe script ion 

GroundObst rue tionLight StatusReport 

Hangar 

Header 

Hole 

Hour sOf Service 

ILSCategorylllUnavailableReport 

ILSCategoryl I StatusReport 

ILSCategoryllUnavailableReport 

ILSCategoryl StatusReport 

ILSCategorylUnavailableReport 

ILSEquipment 

ILSGlidePath 

ILSLocalizer 

ILSMarker 

ILSStatus 
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ILS_DMEStatus 

ILS_DMEStatusReport 

ILS_DMEUnavailableReport 

ILS_MLSFacilityCatI 

ILS_MLSFacilityCatII 

ILS_MLSFacilityCatIII 

ILSdme 

Inst rumen tApproachProcedure 
Inst rumen tApproachProcedureSt a tus 
Inst rumen tApproachProcedureSt a tusRe 
port 

Inst rumen tApproachProcedureUnavai la 
bleReport 

Inst rumen tApproachProcedureUnavai la 
bleStatus 

Inst rumen tApproachProcedures 
Intensity 

Interval Description 

IssuedBylCAO 

LatLon 

LatLonSeq 

Length 

LengthDe script ion 

Light 

Lighted 

LimitedFlights 

Localizer Status 

Local izerStatusReport 

Local izerStatusUnavailableReport 

MLSEquipment 

MLSStatusReport 

MLSUnavailableReport 

MarkerStatusReport 

MarkerStatusUnavailableReport 

Mast 

MeteorologicalEquipment 

MeteorologicalEquipmentOutOf Service 

MeteorologicalEquipmentStatusReport 

MeteorologicalServiceStatus 

MiddleMarker Status 

MilitaryExerciseStatus 

MilitaryNotamlds 

MinimumAltitude 

Mis sileGunRocketFi ring 

MissileGunRocketFiringStatusReport 

ModelFlying 

ModelFlyingStatusReport 

Mul t i In tervalDe script ion 

NDBEquipment 

NOTAMChecklist 

NamedGeoRegion 

Navaid 

NavaidStatus 

NavaidStatusReport 


Nava idUnavail able 

NavaidUnavailableReport 

NavigationUpdateCapability 

NearBy 

NearLatLon 

NearRamp 

NearRunway 

NearTaxiway 

Night 

Normal izedDAML 
Notam 

No tamPart Announcement 

NotamReason 

NotamRef erence 

Notams 

OTSStatus 

Obstacle 

ObstacleClearance 

ObstacleLighted 

ObstacleLightsOTS 

ObstacleMarked 

ObstacleQCode 

Ob stacleUn lighted 

ObstacleWd 

ObstructionWillBeLowered 

Oilrig 

Overt lightRestrictionStatusReport 
PCNSpec 

PacotsTrackAnnouncement 

Parachute Jumping 

Parachute JumpingS t a tusReport 

ParkingAreaClosed 

ParkingAreaStatus 

Permanent Flight In format ion 

Piling 

Pole 

PolygonDe script ion 

PriorPermission 

ProhibitedAir space 

ProhibitedAirspaceActivated 

ProhibitedAirspaceActivationReport 

ProhibitedAirspaceHead 

Pylon 

QATStatus 

QCEStatus 

QSaHoursOf Service 

QSaOu tOf Service 

QScHoursOf Service 

QSeHoursOf Service 

QSeOutOf Service 

QSf Hour sOf Service 

QSfOutOf Service 

QSpHoursOf Service 

QSpOutOf Service 
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QSsHoursOf Service 
QSsOutOf Service 
QS t Hour sOf Service 
QStOutOf Service 
QSvHoursOf Service 
QSvOutOf Service 
QuietHours 
RNAVigation 
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